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Abstract 


Software  Engineering  can  be  viewed  as  the  production  of  a  series  of  models  beginning 
with  a  completely  world-oriented  (application-oriented)  model  and  progressing  toward  models 
that  are  more  and  more  machine-oriented.  In  this  view,  the  first  model  in  the  series,  referred 
to  in  the  thesis  as  a  requirements  model,  should  capture  and  formalize  information  that  is 
usually  left  informal  in  current  approaches.  A  language  for  requirements  modeling  (RML) 
has  been  designed.  It  is  based  on  knowledge  representation  ideas  from  Artificial  Intelligence 
(AI):  a  model  in  RML  is  considered  as  a  knowledge  base  about  some  slice  of  reality.  It 
offers  three  kinds  of  objects  (entity,  activity,  and  assertion)  for  representing  concepts  and 
three  abstraction  principles  (aggregation,  classification,  and  generalization)  for  organizing 
objects.  RML  is  formally  defined  by  giving  a  translation  of  each  of  its  features  into  a  First- 
Order  Logic  with  time.  The  notion  of  consistency  of  a  requirements  model  is  thus  linked  to 
consistency  of  the  corresponding  set  of  FOL  axioms.  Among  other  examples  of  RML  usage, 
the  language  is  used  to  describe  the  organizing  of  an  IFIP  working  conference.  To  offer  some 
methodological  guidance,  RML  is  linked  to  SADT  (Structured  Analysis  and  Design 
Technique,  a  trademark  of  Softech,  Inc.).  SADT  provides  a  technique  for  constructing  an 
initial  'structural  model'  whose  semantics  can  then  be  specified  uring  RML.  RML  was 
designed  as  part  of  the  Taxis  Project  at  the  University  of  Toronto  and  is  based  on  the  same 
framework  as  the  Taxis  language  for  information  system  design. 
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CHAPTER  1 
INTRODUCTION 


1.1  Th«  Problem  and  Approach 

Software  Engineering  can  be  viewed  as  the  production  of  a  series  of  models  beginning 
with  a  completely  world-oriented  (application-oriented)  model  and  progressing  toward  models 
that  are  more  and  more  machine-oriented.  The  first  model  in  the  series,  referred  to  in  the 
thesis  as  a  requirements  models  captures  and  formalizes  information  that  is  left  informal  or  not 
documented  at  all  in  current  approaches.  The  requirements  model  describes  relevant  aspects 
of  a  portion  of  the  world  that  encompasses  the  problem  situation,  including  relevant  existing 
and  foreseen  'systems'  and  their  context/environment.  It  represents  'requirements'  in  the 
sense  that  any  system  developed  to  work  within  the  described  world  must  be  consistent  with 
the  model. 

The  development  of  languages,  methodologies  and  tools  for  requirements 
specifications  is  not  a  new  subject  matter  for  Software  Engineers.  For  example,  [TSE77] 
presents  a  representative  sample  of  projects  oa  requirements  specifications.  Unlike  other 
efforts,  however,  this  thesis  tackles  the  problem  from  the  point  of  view  of  Artificial 
Intelligence  (AI)-  In  this  view,  a  requirements  q>ecification  is  above  all  a  knowledge  base  about 
some  slice  of  reality. 

As  part  of  the  Taxis  Project  at  the  University  of  Toronto  (see  summary  later  in  this 
Chapter),  a  requirements  language  (RML)  was  designed  within  the  Taxis  representational 
framework.  The  work  on  RML  is  part  the  project’s  work  toward  a  unified  methodology  for 
system  development. 

A  major  premise  of  the  project  is  that  the  representation,  or  modeling,  of  application 
world  knowledge  is  of  utmost  importance  to  the  successful  construction  and  use  of  software 
systems.  Requirements  definition,  the  phase  of  Software  Engineering  where  knowledge  about 
some  world  is  studied  in  order  to  understand,  document,  and  analyze  (e.g.  for  consistency)  a 
problem  situation,  is  the  relevant  activity  of  Software  Engineering  where  RML  is  to  be  used 
for  capturing  the  needed  information. 

Languages  for  requirements  modeling  must  offer  facilities  for  the  representation  and 
organization  of  knowledge  into  a  coherent  structure  that  is  understandable  by  its  designer(s), 
by  programmers  building  systems  based  on  a  given  requirements  specification,  and,  ultimately, 
by  end  users  of  these  systems. 

This  research  is  motivated  by  the  fact  that,  in  recent  years,  serious  problems  of 
Software  Engineering  have  been  identified  with  the  requirements  phase  of  software 
development,  in  particular  with  the  form  and  content  of  the  documentation  that  is  produced. 
Poorly  defined  requirements  are  believed  responsible  for  software  project  failures  and  for 
software  that  does  not  meet  user  needs.  Errors  made  in  requirements  and  design  are  the  most 
costly  to  detect  and  correct  fBoehm79],  and  it  is  hard  to  get  the  requirements  right  in  the  first 
place  (BeU761. 
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During  the  Seventies,  there  were  some  significant  developments  in  requirements 
q>ecification  technology.  One  example,  PSITPSA  [Teichroew77],  provides  a  language  and 
computer  facility  for  describing  information  systems.  Another,  RSL  and  the  accompanying 
tools  of  SREM  [Bell77],  apply  to  the  description  of  real-time  systems.  A  third  example  is 
SADT  [Ross77a],  [1]  wMch  provides  a  graphical  language  and  methodology  for  requirements 
definition.  The  interested  reader  can  refer  to  Appendix  A,  where  these  languages  are 
described  in  some  detail. 

It  is  important  to  distinguish  whether  a  language  for  modeling  is  meant  for  describing 
the  problem  situation  ('the  world*)  or  a  solution  system.  Work  on  requirements  definition 
languages  in  the  past  have  dealt  almost  exclusively  with  the  latter  (often  called  'functional 
q>ecification8').  The  features  of  these  languages  describe  what  data  and  processes  there  are  in 
the  system,  with  some  regard  to  interfaces,  ix.  messages,  signals,  data  that  cross  the  boundary 
of  the  system.  The  languages  described  in  Appendix  A  illustrate  this  point. 

In  contrast,  the  problem  of  capturing  and  formally  documenting  the  'problem 
situation*  is  quite  a  new  subject  to  Software  Engineering.  Instead  of  describing  requirements 
in  terms  of  what  is  in  the  system,  we  are  promoting  the  idea  that  the  world  should  first  be 
described  directly,  in  terms  that  are  natur^  for  thinking  about  the  world.  [2]  The  resulting 
model  is  not  a  functional  q>ecification,  but  is  needed  to  interpret  the  functional  specification. 
The  initially  amorphous  and  vague  conceptual  knowledge  about  the  relevant  application 
domains  needs  to  be  formalized  and  documented  in  a  model.  The  model  can  then  be  used  to 
decide  which  aspects  of  the  world  some  solution  systems  should  contain  data  about,  which 
events  in  the  worid  should  be  represented  in  the  system,  which  constraints  arising  in  the  world 
should  be  enforced  for  the  representation  in  the  system,  and  so  on.  In  the  past,  this 
information  has  been  left  undocumented  or  partially  documented  but  in  ad  hoc  ways;  and 
when  documented  at  all,  natural  language  has  mostly  been  used. 

Software  Engineering  has  always  been  concerned  with  the  design  of  formal  languages 
to  document  and  analyze  requirements.  However,  up  to  now,  the  languages  that  have  been 
developed  are  primarily  for  use  after  the  requirements  definition  phase  has  been  undertaken 
and  the  solution  system  for  some  presumably  understood  requirements  is  being  specified.  We 
address  the  earlier  phase  of  capturing  and  formalizing  the  information  that  is  needed  to 
determine  what  system  or  systems  are  needed,  and  we  look  at  the  problem  of  what  language 
goals  and  principles  should  underly  languages  that  support  this  phase. 

The  difficulty  of  the  problem  is  discussed  in  [Ramamoorthy79]: 

'..jiystem  requirements,  needs,  and  objectives  are  generally  vague  and 
ambiguous,  chiefly  because  they  are  at  the  top-level  and  arise  directly  from  the 
application  area  problems.  In  practice,  system  requirements  may  also  include 
the  whole  design  context  of  the  system,  such  as  environmental  design 
constraints  and  criteria  for  evaluating  alternative  designs.  This  information  is 
stated  in  free  form  En^ish  and  sometimes  not  explicitly  at  all. 


(1]  SADT  is  a  trademark  of  Softech,  Inc.,  Waltham  Mass. 

[2]  We  will  discuss  specific  goals  for  an  appropriate  language  later. 
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'Formalization  it  moat  difficult  at  this  level.  It  requiret  complete 
codification  of  all  knowledge  relevant  to  the  design  of  the  system.  However, 
we  may  hope  to  be  able  to  formalize  certain  important  aspects.' 

Natural  language  is  the  most  used  medium  for  documentation  of  this  information, 
when  it  is  documented  at  all,  but  it  has  its  problems.  As  widely  reported  during  the  past  few 
years  (see,  for  example,  (Boehm79],  [^1177],  [Ro8877a],  [YehSOa]),  natural  language 
documentation  leads  to  several  problems,  among  them  the  following:  (a)  unstated  assumptions 
and  undefined  concepts;  (b)  ill-defined  and  ambiguous  terms;  (c)  requirements  mixed  with 
design  and  implementation  decisions;  (d)  monolithic,  poorly  organized,  or  fragmented 
descriptions;  (e)  inconsistent  and  incomplete  descriptions. 

To  reiterate,  we  are  proposing  that  a  formal  language  be  used  in  place  of  or  in 
addition  to  natural  language.  Whether  or  not  an  initial  natural  language  description  is  used, 
the  goal  of  requirements  modeling  is  to  give  a  formal  account  of  a  problem  situation  before 
proceeding  to  functional  system  q>ecification.  Furthermore,  we  propose  that  the  best  way  to 
capture  the  needed  information  is  to  structure  the  description  as  a  conceptual  modeling  (the 
requirements  model)  ix.  a  model  that  reflects  the  content  and  structure  of  the  application 
world,  (which  from  the  viewpoint  of  A1  can  be  looked  upon  as  a  knowledge  base). 

An  early  proposal  for  a  requirements  modeling  scheme  was  made  by  [Wilson75].  More 
recently,  [YehSOa]  and  [BubenkoSl]  have  proposed  work  on  languages  for  requirements 
modeling  and  have  suggested  borrowing  iq>proaches  from  Artificial  Intelligence  and  Database 
Modeling/Information  System  Design.  The  work  in  the  thesis  is  most  closely  related  to  their 
work,  insofar  as  it  proposes  the  application  of  these  ideas  to  Software  Engineering.  [1]  Later 
in  the  chapter,  we  will  survey  related  work  in  Software  Engineering,  as  well  as  the 
background  work  in  Knowledge  Representation  in  Artificial  Intelligence. 

U  Principles  for  a  Rcqolremcnts  Modeling  Langoags 

In  order  to  pursue  this  research,  the  Requirements  Modeling  Language  (RML)  has 
been  designed  as  a  research  tool.  RML  is  a  synthesis  of  a  small  number  of  carefully  chosen 
modeling  ideas  that  are  believed  useful,  or  even  essential,  to  requirements  modeling. 

Certain  general  assumptions  and  principles  form  the  basis  of  RML,  which  we  will  now 

discuss. 


The  requirements  language  should  allow  direct  and  natural  modeling  of  the  world. 
This  is  best  done,  it  is  proposed,  in  an  object-centered  framework.  In  such  a  framework, 
concepts/entities  of  the  world  are  represented  by  units  of  description  called  objects.  The 
creation,  modification,  and  manipulation  of  objects  are  taken  to  represent  the  behavior  of 
their  counterparts  in  the  world.  RML  adopts  an  object-centered  view,  where  all  information 
is  recorded  in  terms  of  objects  which  are  inter-related  by  properties  and  grouped  into  classes 
(and  metaclasses).  The  first  such  schemes  to  be  investigated  were  semantic  network  schemes 
from  Artificial  Intelligence  [QuiUianfiS],  which  posed  a  theory  about  how  knowledge  is 
represented  and  processed  by  humans.  Semantic  networks  share  common  premises  with 
object-centered  programming  languages  such  as  Simula  and  Smalltalk,  with  various  Entity- 
Relationship  approaches  [Chen76],  with  Database  models  [Abrial74],  and  Office  Systenu 
[Gibbs83]. 


[1]  Similar  arguments  for  the  importance  of  world  modeling  are  advanced  by  [Jackaon83]  but 
not  within  the  context  of  knowledge  representation. 
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A  requirements  language  should  support  the  organization  and  intellectual 
nuinagement  of  large  descriptions.  As  has  often  been  said,  the  best  tool  we  have  for  this  is 
abstraction^  which  is  the  ability  to  consider  only  the  essential  information  needed  for  some 
purpose  while  suppressing  subordinate  information.  Within  an  object-centered  representation 
scheme,  useful  abstraction  principles  are  aggregation^  classification,  and  generalization  (ISA- 
hierarchies)  [Smith77,79],  [MylopotdosSO],  which  we  will  also  use  for  RML. 

A  requirements  modeling  language  should  allow  the  expre^ion  of  assertions  (what 
should  be  true  in  the  world),  as  well  as  entities  (the  'things'  in  the  world)  and  activities 
(happening;i  that  cause  change  in  the  world).  To  describe  these  three  types  of  information, 
RML  provides  three  kinds  of  objects.  Current  languages  are  usually  based  on  some 
combination  of  entities  and  relationships  ([Chen76],[Teichroew77],  and  others)  or  proce»es 
([ZaveSl],  [DeWolf77]).  Although  constraints  are  especially  important  for  expressing 
requirements,  current  languages  usually  provide  facilities  for  natural  language  comments 
instead.  For  assertions,  RML  will  have  the  power  of  First-Order  Logic,  since  obviously  many 
constraints  involve  quantification. 

Uniformity  in  the  use  of  basic  principles  is  important  to  make  the  language  easy  to 
learn  and  use.  For  this  reason,  RML  applies  the  framework  of  classes,  properties,  and 
abstraction  principles  uniformly  to  all  three  kinds  of  objects.  Entities  form  classes  of  objects 
that  have  the  same  types  of  parts,  invariants,  and  other  properties.  Activities  form  classes  of 
objects  that  share  the  same  types  of  inputs,  outputs,  activation  conditions,  etc.  Assertions 
form  classes  of  objects  that  make  statements  about  the  same  types  of  arguments,  are 
structured  using  the  same  types  of  terms,  and  so  on. 

A  requirements  modeling  language  should  be  formal,  ije.  its  features  should  be 
precisely  defined.  This  is  important  if  the  features  of  the  language  are  to  be  well-understood 
and  it  is  necessary  if  one  wants  to  have  a  precise  meaning  of  'well-formed'  and  'consistent'. 
A  translation  from  RML  into  a  First-Order  Logic  (FOL)  with  time  provides  the  formal 
definition  of  RML;  thus,  an  RML  model  is  equivalent  to  a  theory  stated  as  a  set  of  axioms  in 
FOL.  We  can  take  as  given  the  standard  notions  of  semantics,  model  theory,  [1] 
interpretation,  and  logical  consistency.  [Mendelson64] 

By  'formal'  language,  we  clearly  mean  one  whose  semantics  is  based  on  a 
mathematical  formalism.  This  does  not  mean,  however,  that  the  formalism  used  for  such  a 
semantics  is  necessarily  a  good  language  for  requirements  modeling.  We  contend,  therefore, 
that  while  logic,  algebraic,  and  other  formal  approaches  to  specification  may  be  useful  for 
theoretical  underpinninga,  their  notations  should  not  be  given  to  the  user  as  a  modeling 
language.  Also,  it  is  desirable  to  combine  the  advantages  of  several  approaches  into  a  single 
framework,  while  a  common  formalism  can  be  given  to  explain  how  the  framework  fits 
together. 

For  large-scale  models,  there  must  be  a  requirements  modeling  methodology  offering 
guidance  to  the  modeler.  The  popular  'box-and-arrow'  languages  provide  guidance  for 
introducing  terms  of  the  domain  of  discourse  into  an  initial  structure  but  do  not  impart 
semantics  to  the  terms.  A  language  such  as  RML  can  then  be  used  to  impart  semantics  to  the 
introduced  terms.  The  box-and-arrow  language  thus  serves  to  bridge  the  gap  between  our 
mental  models  and  the  formal  requirements  model.  We  have  chosen  to  link  RML  to  SADT, 


[1]  Note  the  two  different  uses  of  'model'  here:  (1)  an  RML  model  'models'  (describes, 
represents)  things  in  the  world;  (2)  the  semantics  of  a  language  are  given  using  model  theory, 
ijc.  a  mapping  from  the  language  to  a  suitable  mathematical  model. 
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[2]  becaiue  its  notation  is  ccrefuUy  defined,  and  it  haa  been  used  extensively  in  practice. 

L3  Belated  Wort 

Related  work  to  RML  and  the  goals  of  the  thesis  are  discussed  in  three  parts: 

First,  proposab  of  a  similar  nature  by  other  researchers  are  discussed;  since 
there  is  a  strong  relationship  between  requirements  modeling  in  Software 
Engineering  and  'Corporate  Requirements'  in  the  area  of  Information 
Systems,  a  discussion  of  this  area  is  covered  as  well. 

Second,  the  area  of  Knowledge  Representation  in  A1  is  discussed. 

Third,  since  this  work  has  been  done  as  part  of  the  Taxis  Project,  we  discuss 
RML  in  the  context  of  Taxis. 

L3.1  Conceptaal  Modeling  In  Software  Engtnccrtng 

The  first  proposal  for  a  semantics-based  framework  specifically  proposed  for 
requirements  came  from  [WilsonTS].  His  framework  used  abstraction  principles  similar  to 
those  we  use  in  RML.  His  implementation  translates  the  conceptual  model  into  a  relational 
database  model,  and  he  has  prescribed  a  multistep  process  for  doing  requirements  and  design 
based  on  his  approach  [WilsonSl]. 

Elsewhere,  Yeh  and  his  colleagues  proposed  the  use  of  conceptual  modeling  in 
Software  Engineering,  advocating  cross-fertilization  from  Databases  and  AI  to  find  good 
modeling  approaches  [YehSOa,  YehSOb,  MittermeirSOb,  Mittermeir82a,  Mittermeir82b]. 

A  language  proposed  for  this  modeling  is  presented  in  [Roussopoulos79].  The 
language  gives  a  pictorial  representation  of  concepts  in  a  frame-based  [MinskyTS]  semantic 
network  framework  with  ISA  hierarchies. 

The  area  of  Information  Systems/Database  Management  shares  with  Software 
Engineering  this  concern  over  the  initial  phase  of  requirements.  Recently,  database 
researchers  carved  out  an  area  of  special  concern  called  'Corporate  Requirements  Analysis  ... 
an  analysis  of  the  corporation  needs  without  any  concern  to  constraints  other  than  the  manner 
in  which  the  corporation  does  its  business.'  [Lum79]  Modeling  for  this  purpose  is  being 
approached  in  the  Database  area  by  looking  for  ways  to  extend  current  data  models.  This 
task  involves  modeling  for  the  purpose  of  'communication  and  understanding'  and  thus  arises 
from  different  motives  than  in  the  area  of  database  modeling.  Information  System  Modeling  in 
the  more  usual  sense  (defined  as  the  subsequent  task  to  corporate  requirements  in  [Lum79]). 

The  Information  Systems  area  is  an  an  abundant  source  of  modeling  ideas  (e.g.  see 
[TsichritzisSl],  [Kent78]).  The  primary  purpose  of  data  models  was  originally  to  describe  the 
data  in  the  system  in  a  manner  independent  of  physical  implementation,  rather  than  to  model 
the  world,  but  the  more  recent  work  on  the  so-called  'semantic  data  models'  [Brodie83]  has 
been  increasingly  concerned  with  what  the  data  represents  in  the  world.  [2]  The  consensus  of 


[1]  SADT  is  a  trademark  of  Softech,  Inc. 

[2]  As  pointed  out  in  [Yeh80a],  'The  notion  of  Conceptual  Model  should  nor  be  confused  with 
the  traditional  notions  of  Data  Model  and  Conceptual  Schema  that  appear  in  Data  Base 
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nLum79]  is  that,  at  present,  data  modeb  are  still  weak  in  some  respects.  As  weak  areas, 
[SmithSO]  identify  the  modeling  of  dynamic  aspects  of  the  r/orld  (change,  events,  operations) 
and  constraints. 

Among  recent  work  in  the  Information  System  area,  Bubenko’s  b  the  most  related  to 
oiir  goab  [BubenkoSO,  BubenkoSl].  He  promotes  a  'goal-oriented'  strategy  which  'implies 
that  the  user  defines  all  information  requirements  in  terms  of  a  theory  of  an  application  and 
by  stating  operational  criteria  (objectives)  which  must  be  satbfied  in  order  to  consider  the 
future  system  a  successful  one',  as  opposed  to  a  'solution-oriented  requirements  specification 
[which]  b  normally  presented  in  terms  of  data  sets  (and  flows),  and  rules  for  process  initiation 
and  synchronization.'  [BubenkoSl,  page  9]  Thb  view  b  quite  consbtent  with  our  requirements 
modeling  approach. 

Certainly,  there  is  a  tremendous  amount  of  research  in  the  Database  and  Information 
System  areas  from  which  we  can  learn,  and  have  learned,  a  great  deal  (See,  for  example,  the 
numerous  conferences  on  Systemeering,  Entity-Relationship  approaches,  and  so  on.) 

In  particular,  we  credit  [Abrial74]  with  the  introduction  of  an  influential  object- 
oriented  framework  into  Databases,  and  [Smith77]  with  the  introduction  of  the  abstraction 
principles  into  Databases,  and  the  introduction  of  semantic  networks  into  Databases  by 
[Rou8sopoulos75].  Especially  relevant  are  the  investigations  by  th<»e  seeking  ideas  across  the 
boundaries  of  several  fields  [PingreefiO,  Brodie83]. 

U  J  Knowledse  Representation  In  Artificial  Intelligence 

The  goab  of  requirements  modeling  languages  have  much  in  common  with  those  of 
Knowledge  Representation(KR)  languages  in  Artificial  IntcIligence(AI).  Both  attempt  to 
provide  toob  for  the  representation  of  real  world  knowledge,  such  as  concept  definitions, 
assumptions,  constraints  and  event  descriptions.  The  resulting  structures  (requirements 
models,  knowledge  bases)  are  expected  to  be  natural  and  direct  representations  of  the 
knowledge  they  embody  so  that  they  can  facilitate  communication  between  domain  experts, 
system  builders  and,  ultimately,  system  users. 

The  survey  by  Brachman  and  Smith  [BrachmcnSO]  b  indicative  of  the  variety  and 
extent  of  the  work  in  thb  area. 

Several  important  representational  issues  have  been  addressed  in  KR  but  are  only  now 
being  examined  for  requirements.  The  Ibt  of  such  issues  includes  organization  of  a  model 
(knowledge  base),  consbtency,  reasoning  with  respect  to  a  model  and  the  representation  of 
exceptions  and  defaults.  This  thesb  argues  that  these  issues  are  important  in  Software 
Engineering  and  that  KR  techniques  can  be  adopted. 

There  b  a  common  misconception  about  AI  that  KR  techniques  are  intended  for  use 
only  in  building  'expert'  systems.  The  research  reported  here  b  a  counterexample  to  thb 
notion  and  demonstrates  that  KR  can  be  useful  even  if  one  does  not  intend  to  create  an 
'artificial  intelligence'.  [1] 


literature.  The  Conceptual  Model  represents  a  description  of  the  context  of  a  software 
system,  not  a  description  of  the  information  stored  in  it,  as  b  the  case  for  Data  Models.' 

[1]  One  might  point  out,  however,  that  if  one  wbhes  to  specify  and  build  systems  that  are 
'intelligent'  in  the  sense  that  they  make  complex  deebiens,  or  are  flexible  or  user-friendly. 
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Experience  ihows  that  KR  tcchniquea  facilitate  the  understanding  of  application 
domains.  The  acquisition  of  knowledge  from  human  experts  for  the  purpose  of  KR  demands 
intense  involvement  with  the  subject  matter  of  the  application  domain.  In  the  field  of 
medicine,  for  example,  knowledge  from  physicians  about  diseases,  medical  procedures, 
hospital  procedures,  and  diagnosis  have  been  been  encoded  in  KR  languages;  knowledge  about 
chemistry  and  geology  have  been  captured;  and  physical  bodies  and  time  have  been  formalized 
and  analyzed.  The  existence  of  an  appropriate  medium  for  encoding  this  knowledge  has  been 
indispensable  in  these  endeavors  and  has  even  led  to  significant  advancements  in  the  state  of 
knowledge  in  that  domain.  Understanding  the  problem  domain(s)  is  an  absolute  prerequisite 
to  btiilding  correct,  reliable  systems,  and  KR  techniques  have  proved  extremely  useful  in  this 
respect. 


Several  different  types  of  representation  techniques  have  been  proposed  and  used  in 
A1  over  the  past  15  years.  These  techniques  can  be  categorized  as  procedural,  logical,  or 
network  approaches  [MylopoulosSO],  each  having  advantages  and  disadvantages  for  different 
applications.  One  category,  known  as  semantic  networks^  represents  the  world  by  constructing 
a  graph-like  model  of  interrelated  'objects'.  Semantic  networks  have  particular  advantages 
w^ch  we  would  like  to  exploit  for  requirements  modeling. 

First,  objects  can  be  used  to  represent  entities,  events,  constraints,  or  any  other 
category  of  conceptual  unit  of  information  about  the  world,  and  therefore  semantic  networks 
can  be  used,  in  fact,  as  a  'hybrid*  approach,  combining  the  advantages  of  the  various 
approaches. 

Second,  there  has  been  emphasis  on  organization/abstraction  principles.  The  most 
important  and  popular  of  these  is  the  notion  of  ISA-hierarchies,  which  organizes  concepts  by 
their  generality/^)ecificity.  It  is  considered  a  reasonable  goal  that  a  small  set  of  primitive 
semantic  relationships  should  form  the  framework  for  representation  technique  (see 
[Brachman79D. 

Third,  for  some  time,  at  least  since  [Woods75],  there  has  been  q>ecial  attention  in 
semantic  network  research  on  clearly  making  semantic  distinctions  and  on  well-defined  formal 
mathematical  underpinnings  for  representation  languages. 

Advocates  of  KR  techniques  in  Software  Engineering  exist,  as  acknowledged  above, 
but  are  few  in  number,  and  woi^  in  this  area  is  just  beginning.  The  work  reported  in  this 
thesis  therefore  is  aimed  mainly  at  establishing  a  bridge  across  the  border  to  AI,  with  the 
idea  of  opening  the  door  to  future  importing  of  ideas  and  technology. 

U  J  The  Taxis  Project 

RML  is  part  of  Taxis  Project  at  the  University  of  Toronto.  The  focus  of  the  project  is 
the  programming  language  Taxis  [MylopoulosSOa],  which  treats  several  aspects  of  information 
system  description  within  the  same  concise  uniform  framework.  Taxis  is  related  to  the 
semantic  network  framework  of  Procediu’al  Semantic  Networks  (PSN)  [Levesque79]  but 
adapted  to  information  system  design.  RML  has  been  designed  to  be  compatible  with  Taxis. 
A  unified  approach  to  Software  Engineering  is  envisioned  in  which  RML  is  used  for 
requirements  and  Taxis  is  used  for  information  system  design.  [Greenspan83,  Grecnspan82b] 


knowledge  about  the  complex  environment  of  the  system  must  be  captured  in  the 
requirements  model. 


As  s  means  of  achieving  a  concise,  uniform  framework,  the  Taxis  Project  has  been 
strongly  guided  by  the  premise  that  there  exists  a  set  cf  abstraction  mechamsms  that  can  be  used 
to  structure  all  pewts  of  a  specification.  This  premise  is  meant  to  aj^iy  to  requirements  models, 
design  specifications,  programs,  or  any  other  kind  of  description. 

The  premise  asserts,  on  the  one  hand,  that  people  find  it  natural  and  e^>edient  to 
organize  descriptions  of  worlds/systems  in  terms  of  a  small  number  of  appropriate  abstraction 
mechanisms,  and  on  the  other  hand,  that  a  framework  based  on  them  facilitates  a  systematic 
and  productive  progression  from  initial,  world-oriented  requirements  to  increasingly  more 
oonq>uter-oriented  system  design  and  implementation  specifications. 

RML  shares  with  Taxis  and  PSN  the  framework  of  abstraction  principles  described 
above.  Like  Taxis,  RML  has  a  bounded  number  of  classification  levels,  (with  three  levels  -- 
tokenst  classes^  and  metaclasses  ~  believed  adequate  for  most  purposes.  (TCN  allows,  through 
recursion,  a  theoretically  unbounded  number  of  levels.) 

The  object  and  property  types  of  RML  are  chosen  to  be  appropriate  to  requirements 
modeling,  as  opposed  to  these  of  Taxis,  which  are  chosen  for  usefulness  in  information  system 
modeling. 

RML  differs  from  both  Taxis  and  its  PSN  ancestor  by  making  assertions,  rather  than 
procedures,  the  basic  expression  level  of  the  language  -  as  well  as  the  basis  for  the  semantics 
of  the  language. 

Taxis  has  a  semantic  model  which  organizes  both  data  and  transactions  into  classes 
placed  on  ISA  hierarchies.  Taxis  also  provides  Scripts,  which  model  interaction  between  users 
and  the  system  using  a  framework  that  combines  Augmented  Petri  Nets  [Zisman78]  with 
Hoare’s  communication  primitives  [Hoare78]. 

In  [Greenq)an82b]  we  discuss  methodological  issues  of  information  system 
development  based  on  first  uring  RML  for  requirements  modeling  and  then  using  Taxis  for 
system  design.  Some  of  the  steps  to  get  a  Taxis-based  information  system  from  RML  would  be 
(i)  implementing  activities  as  either  Scripts  or  transactions,  (ii)  choosing  certain  RML  data  to 
be  part  of  the  information  system  by  making  Taxis  data  classes,  and  (iii)  converting  assertions 
into  Taxis  expressions  playing  various  roles. 

The  Taxis  approach,  with  RML,  would  differ  from  the  usual  Software  Engineering 
approach  using  a  functional  specification.  The  functional  specification  typically  describes 
system  interfaces 
system  data  and  processes 
input/output  data(messages) 
while  the  Taxis  method  describes 

definition  of  concepts 
user/system  interaction 
system  data  and  transactions 

The  first  difference  is  that  the  usual  Software  Engineering  approach  does  not  have  a  formal 
definition  of  concepts,  as  done  by  RML.  Another  difference  is  that  the  Taxis  data  model 
captures  more  of  the  semantics  of  the  system  data  and  processes  than  a  functional 
q)ecification  language,  since  it  has,  for  example,  the  abstraction  mechanisms  built  in.  Yet 
another  difference  is  that  Scripts  capture  much  more  about  the  intended  use  of  the  system 
and  how  it  must  reqMmd  to  its  environment  than  functional  specification  methods;  the  latter 
have  only  limited  facilities  for  modeling  the  environment(e.g.,  the  tree-structured 
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INTERFACE  objects  of  PSL).  Unlike  many  systems  analysis  techniques  that  use  graphical 
notations  for  sketching  out  the  flow  of  information  in  an  organization.  Scripts  become  part  of 
the  system  and,  by  keeping  track  of  the  state  of  the  user  interaction  and  communication,  can 
be  used  for  scheduling,  decision-making,  notification,  and  other  'intelligent'  actions  that  are 
currently  of  interest  (e.g.  in  office  automation  [Oibbs83]). 

The  Taxis  methodology,  using  RML,  seems  to  concur  with  Winograd’s  proposal 
p0V'inograd79],  where  his  three  domains  of  description  -  subject,  interaction,  and 
implementation  -  seem  to  correspond  to  the  levels  of  RML,  Scripts,  and  the  Taxis  language, 
respectively. 

1.4  Thesb  Overview 

1.4.1  Overview  of  Contrlbotions 

One  of  the  main  contributions  of  the  thesis  is  the  design  of  a  language  for 
requirements  modeling.  The  language  demonstrates  a  new  approach  to  capturing 
requirements,  one  that  uses  knowledge  representation  concepts  from  Artificial  Intelligence 
and  treats  the  initial  information-gathering  stage  of  requirements  definition  as  a  modeling,  or 
knowledge  representation,  activity.  This  establishes  a  link  between  Software  Engineering  and 
A1  which  can  be  further  exploited  in  the  future.  (We  will  discuss  some  of  the  research  issues 
in  Chapter  6.) 

RML  consists  of  a  representative  sampling  of  features  of  current  requirements 
languages,  such  as  activities  (events,  processes);  inputs,  outputs,  controls;  preconditions, 
postconditions,  activation  conditions,  invariants;  and  others.  However,  RML  differs  from 
previous  languages  in  several  important  respects. 

First,  it  combines  three  approaches  to  ^>ecification  -  procedural,  logical,  and  data 
modeling  -  into  a  single,  uniform  framework.  Assertions  treated  as  objects  are,  in  particular, 
novel  in  a  requirements  language.  Assertions  as  objects  allow  information  expressed  as  logical 
formulas  to  be  used  in  the  definitions  of  objects  just  as  other  objects  are  used  and  to  be 
organized  according  to  the  same  principles  (into  classes  of  objects  that  are  arranged  on  an  ISA 
hierarchy  and  decomposed  into  parts,  etc.). 

Second,  abstraction  principles,  shown  useful  previously  in  other  areas  such  as 
Databases,  AI,  and  programming  languages,  are  applied  here  to  requirements. 

A  third  difference  is  that  RML  has  a  formal  definition,  namely  a  translation  into 
First-Order  Logic.  Although  the  features  of  the  language  are  varied,  the  underlying  definition 
shows  that  there  are  actually  a  small  number  of  basic  patterns  at  work.  Previous  requirements 
languages  have  been  most  often  'defined  by  their  implementations',  i.e.  programs  that  give 
error  messages  for  ill-formed  specifications.  An  RML  model  q;>ecifies  a  theory  in  First-Order 
Logic  and  is  consistent  if  and  only  if  the  corresponding  theory  is  consistent. 

Two  examples  of  the  power  and  expressibility  of  the  language  are  its  ability  to 
represent  vague  time  concepts  and  also  metaknowledge.  This  information  is  described 
formally  within  the  descriptive  framework,  not  outside  as  comments. 
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One  of  the  most  difficult  problems  for  requirements  modeling  (and  for  knowledge 
representation  and  database  modeling  as  well)  is  the  methodological  one  concerning  how  one 
should  go  about  the  task  of  constructing  a  model/specification.  The  language  issues  present 
interesting  and  difficult  technical  problems  (and  there  are  management  problems  as  well 
[Yadav83]).  RML  is  designed  to  be  compatible  with  SADT  so  that  it  is  relatively 
straightforward  (but  involves  design  choices)  to  proceed  from  an  SADT  model  to  an  RML 
model.  The  connection  between  the  two  levels  draws  a  distinction  between  two  conceptually 
different  modeling  tasks,  and  the  mapping  from  one  level  to  the  next  defines  a  specific  task 
for  cooq>uter-as8isted  requirements  m^eling. 

Finally,  this  research  has  opened  up  the  way  to  a  new  Software  Engineering  paradigm 
that  emphasizes  the  representation  of  knowledge  as  an  essential  step  in  system  development 
and  maintenance  of  a  knowledge  base  as  an  essential  component  of  a  system  throughout  its 
lifetime. 

1,4  J  Organization 

The  language  for  requirements  modeling,  RML,  is  described  in  Chapter  2.  Chapter  3 
presents  the  formal  definition  of  RML.  In  Chapter  4,  RML  is  developed  for  use  in  specifying 
metaknowledge  and  for  representing  time  concepts.  Chapter  5  presents  the  SADT-RML 
connection.  Chapter  6  is  the  concluding  Chapter,  in  which  contributions  are  summarized  and 
future  work  discussed. 

Appendix  A  contains  the  survey  of  features  of  the  functional  requirements  languages 
mentioned  earlier.  Appendix  B  contains  a  summary  of  syntax  and  semantics  for  RML. 
Appendix  C  gives  a  model  of  'organizing  an  IFIP  working  conference*  as  an  extended  example 
of  using  RML. 
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CHAPTER  2 

REQUIREMENTS  MODELING  LANGUAGE  (RML) 


This  chapter  presents  the  Requirements  Modeling  Language  (RML).  The  most 
important  aspect  of  RML  is  its  semantic  framework.  The  syntax  is  considered  relatively 
unimportant.  A  formal  definition  of  the  language  appears  in  the  next  chapter.  A  summary  of 
RML  syntax  and  semantics  is  given  in  Appendix  B. 

The  features  can  be  described  roughly  as  an  appropriate  ehoice  of  object  and 
relationship  types  in  the  style  of  PSL,  RSL,  or  SADT,  among  others  (see  Appendix  A).  The 
goal  is  to  demonstrate  that  the  features  of  a  requirements  language  can  be  contained  in  a 
framework  that  on  the  one  hand  is  natural  and  direct  for  modeling  the  world  and  on  the 
other  hand  is  concise  and  amenable  to  formalization. 

The  choice  of  an  object-oriented  (semantic  network)  framework  (as  opposed  to  a 
rule-based  approach  or  a  logic-only  approach  for  example)  is  partly  due  to  the  fact  that 
current  descriptive  facilities  such  as  those  mentioned  above  as  well  as  a  host  of  so-called 
entity-relationship  approaches  are  proving  quite  useful  in  practice;  furthermore,  evidence  of 
the  usefulness  of  object-oriented  approaches  is  growing  in  several  areas  of  computer  science 
and  software  applications,  as  mentioned  in  Chapter  1.  One  of  the  advantages  of  these 
approaches  is  that  they  seem  to  offer  good  intuition  about  the  connection  between  objects  in 
the  world  and  the  objects  in  the  model  that  represent  them.  Also,  it  is  possible  to  treat  the 
artifacts  of  other  approaches  (e.g.  rules,  assertions,  etc.)  as  objects  within  an  object-oriented 
framework;  a  consequence  is  that  the  same  organizational  principles  can  be  applied  to  all  the 
kinds  of  objects. 

RML*s  choice  of  entity  and  activity  objects  was  based  on  on  their  importance  to 
languages  such  as  SADT.  Since  constraints  form  an  important  and  natural  part  of 
requirements,  and  are  useful  in  general  for  describing  things,  assertions  were  added  to  the 
framework.  An  implicit  advantage  of  having  a  assertions  in  the  language  is  that  one  knows 
that  one  has  at  least  the  power  of  the  logic  used  for  expressing  them  as  one  tool  for 
description. 

As  the  reader  will  see,  RML  is  based  on  three  levels  of  'classification*  (there  are 
'classes*  and  'classes  of  classes').  There  is  nothing  magical  about  three  levels,  but  three  seem 
adequate  for  all  of  the  examples  encountered,  and  it  was  considered  an  advantage  to  conform 
to  the  Taxis  framework  whenever  there  was  no  clear  reason  not  to,  since  the  connection 
between  RML  and  Taxis  is  to  be  investigate  (see  Chapter  6). 


2.1  Bade  concepts  of  RML 

An  RML  model  consists  of  a  set  of  inter-related  specification  units,  called  object 
definitions.  Each  definition  d«Kribes  some  real-world  phenomenon,  concept,  entity,  etc., 
whose  representation  in  the  model  is  called  an  object.  The  language  can  be  described  simply 
in  terms  of  the  kinds  of  specification  units  it  offers,  and  the  organizational  principles  it  uses. 
For  units  of  q>ecification,  there  are  three  categories  of  objects  in  RML.  For  organizational 
principles,  a  small  number  of  {distraction  mechanisms  are  used.  These  are  discussed  in  the 
following  two  sections. 

2.1.1  The  Abstraction  Mechanisms 

A  property  is  a  directed  relationship  between  one  object  and  another,  in  terms  of 
which  the  first  is  defined.  Aggregation  allows  one  to  view  an  object  as  a  collection,  or 
aggregatet  of  the  objects  to  which  it  is  related  by  properties.  The  'abstraction"  here  is  that 
one  may  talk  about  an  object  while  ignoring  its  'components^;  conversely,  one  can  refer  to  the 
con^mnents  of  the  object  ('property  selection'). 

Classification  allows  one  to  group  individuals  that  share  common  properties  into  a 
class  (e.g.  representing  all  persons)  and  to  talk  about  the  class  as  a  set  or  as  a  generic  concept 
without  talking  about  specific  members,  called  instances.  Defitutiontd  properties  of  a  class 
q>ecify  general  characteristics  that  apply  to  all  instances  (e.g.  every  person  has  a  mother  and  a 
father),  which  induce  factual  properties  of  its  instances  (e.g.  'mother’  and  'father*  for  a 
particular  person). 

Gene!  alizcuiont  and  its  converse  specialization^  allow  for  organizing  classes  into  a 
hierarchy  from  most  general  to  most  specialized.  One  class  is  a  specialization,  or  subclass,  of 
another  (a  superclass)  if  every  instance  of  the  first  is  invariably  an  instance  of  the  second.  The 
most  important  consequence  of  this  organization  is  that  (definitional)  properties  can  be 
inherited  down  the  hierarchy.  Such  an  organization  is  efficient^  since  properties  can  be 
associated  with  the  most  general  applicable  class,  and  natural^  because  the  more  two  classes 
have  in  common,  the  closer  they  will  be  on  the  hierarchy.  This  abstraction  principle  has  been 
used  for  a  long  time  in  Artificial  Intelligence  under  the  name  of  ISA-hicrarchies. 

In  RML,  classification  is  realized  by  distinguishing  three  'classification  levels':  token, 
class,  metaclass.  A  token  is  an  instance  of  one  or  more  classes  but  has  no  instances  of  its  own; 
a  class  is  an  instance  of  one  or  more  metaclasses  and  has  tokens  as  instances;  a  metaclass  has 
classes  as  instances.  The  RML  modeler  can  define  objects  only  on  these  three  levels. 

A  property  has  three  parts:  an  identifier,  called  the  property  name,  or  attribute,  the 
object  being  defined,  called  the  subject,  and  the  object  to  which  the  subject  is  related,  called 
the  property  value.  An  example  would  be  the  triple 

<  john-smith,  age,  23> 

expressing  that  the  age  of  token  john-smith  is  the  value  23.  This  is  an  example  of  a  factual 
property.  [1]  The  triple 

(PERSON,  age,  AGE_VALUE) 

indicates  that  all  instances  have  an  kind  of  property  called  a  definitional  property,  [2]  because 
it  defines  what  kind  of  facts  may  be  specified  about  instances  of  the  subject,  PERSON,  rather 


[1]  We  use  angle  brackets  here  to  designate  factual  properties. 

[2]  We  use  parentheses  to  designate  definitional  properties. 
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than  specifying  a  fact  itself.  Every  instance  of  PERSON  must  have  a  factual  property 
corresponding  to  each  definitional  property  of  PERSON,  e.g.  since  (a)  john-smith  is  an 
instance  of  PERSON  and  (b)  PERSON  has  the  ’age’  definitional  property,  therefore  (c)  john- 
smith  must  have  a  factual  property  also  named  *age’  and  having  as  property  value  some 
instance  of  AGE_VALUE.  Classes  and  metaclasses  are  said  to  induce  factual  properties  of 
their  instances  (where  the  instances  are  tokens  and  classes,  respectively). 

Generalization  is  realized  by  a  relationship,  subclass,  (or  isa)  between  two  classes  (or 
between  two  metaclasses).  To  say  that  PERSON  is  a  generalization  of  CHILD  (conversely, 
CHILD  is  a  subclass,  or  specialization,  of  PERSON)  means  that  every  member  of  the  class 
CHILD  is  a  member  of  the  class  PERSON.  Moreover,  in  a  consistent  RML  model,  every 
definitional  property  attributable  to  a  person  must  be  attributable  to  a  child.  [1] 

For  ezample,  since  (a)  class  CHILD  is  a  specialization  of  PERSON  and  (b)  PERSON 
has  the  definitional  property  (PERSON,  age,  AGE_VALUE),  therefore  (c)  CHILD  has  an 
’age’  definitional  property,  and  to  be  consistent,  the  definitional  property  value  for  the  ’age’  of 
CHILD  must  be  a  specialization  of  (or  the  same  class  as)  AGE_VALUE.  For  example,  the 
’age’  definitional  property  for  CHILD  could  be  declared  to  be  (CHILD,  age,  AGE_VALUE), 
or  it  could  be  declared  to  be  (CHILD,  age,  CHILD_AGE_VALUE),  in  which  case  one  must 
also  declare  that  CHILD_AGE_VALUE  isa  AGE_VALUE. 

Thus,  entity,  activity,  and  assertion  objects  are  defined  through  aggregation  by  their 
relationships  to  other  objects  of  all  three  kinds.  For  ezample,  an  activity  can  be  related  to 
entity  objects  serving  as  inputs  and  outputs,  to  assertions  serving  as  preconditions, 
postconditions,  and  trigger  conditions,  and  to  activities  as  parts. 

In  applying  classification,  a  natural  and  useful  way  of  forming  classes  (metaclasses)  for 
all  three  kinds  of  objects  had  to  be  invented.  What  does  it  mean  to  have  classes  of  activities 
and  classes  of  assertions?  For  activities  and  (eq)ecially)  assertions,  this  use  cf  the  abstraction 
principles  is  particularly  novel  and  interesting.  Once  this  is  achieved,  generalization 
hierarchies  can  then  be  used  to  organize  all  of  the  objects  in  the  model. 

The  above  discussion  can  be  summarized  by  expressing  a  handful  of  constraints  that 
are  central  to  the  framework  of  RML.  These  follow.  When  we  refer  to  a  null  property  value, 
we  mean  that  the  property  value  is  the  special  object  nothing;  when  a  property  ^ue  is  nothing, 
it  is  the  same  as  saying  that  the  property  has  no  value. 

Property  induction  constraint  -  For  a  definitional  property  with  subject  C,  attribute  i,  and 
value  D,  each  instance  of  C  has  an  i  factual  property  with  a  value  that  is  an  instance 
of  D  or  null. 

Exsensional  ISA  constraint  —  If  C  ISA  D  then  every  instance  of  C  is  an  instance  of  D. 

Intentional  ISA  constraint  -  If  C  ISA  D  then  every  definitional  property  i  of  D  is  also  a 
definitional  property  of  C,  and  furthermore,  the  value  of  property  i  for  C  ISA  the  i- 
value  for  D. 


[1]  In  many  schemes  that  en^>loy  an  Isa  relationship,  the  relationship  is  used  to  say  both  that 
an  object  is  an  instance  of  a  class  (e4.  John  is  a  student)  and  that  one  class  is  a  specialization 
of  another  (a  student  is  a  person).  In  our  treatment,  isa  expresses  only  the  latter  type  of 
relationship. 


2.U  The  Object  Cetegorlee 


For  units  of  specification,  RML  provides  objects  of  three  kinds:  entity,  activity, 
assertion.  These  are  called  the  object  categories  of  RML. 

Each  property  q>ecified  for  an  object  must  be  in  one  of  a  prescribed  set  of  property 
categories,  which  constrain  the  kind  of  relationship  e]q!»ressed  by  the  property.  Property 
categpries  typically  q>ecify  such  things  as  (a)  in  which  object  category  must  the  property  value 
be,  (b)  whether  the  property  value  can  change  over  time,  (c)  whether  the  property  value  must 
always  have  a  non-null  value.  Which  object  category  is  chosen  for  modeling  a  concept/entity 
depends  mostly  on  which  one  provides  the  most  convenient  property  categories  for  modeling 
the  concept.  The  property  categories  of  RML  were  chosen  to  satisfy  two  criteria:  first, 
commonly  used  relationship  types  in  other  modeling  languages  should  be  'covered*,  and 
second,  the  property  categories  should  be  unifiable  into  a  simple  framework  based  on  a  small 
number  of  notions.  With  respect  to  these  criteria,  RML  can  compared  to  other  languages, 
but  since  this  is  a  new  area,  there  are  not  many  to  compare  with.  One  of  the  closest  related 
languages  is  that  of  [Roussopoulos79]  (also  [MittermeirSO]),  but  it  is  based  on  case  grammar 
roles  ('subject',  'object*,  'destination',  etc.)  and  do  not  have  a  specific  semantics. 

Entitles 


Entities  are  the  most  familiar  to  us  because  of  the  experience  of  data  models.  Entities 
represent  the  'things'  in  the  world,  such  as  persons,  places,  equipment,  etc.  In  contrast  to 
data  models,  however,  RML  entity  objects  are  not  necessarily  things  about  which  some 
information  system  will  store  information;  further  analysis  is  needed  to  determine  which 
objects  will  have  information  about  them  stored. 

Entity  tokens  represent  individuals  in  the  domain  of  discourse,  and  entity  classes  are 
collections  of  these  tokens  that  share  properties.  By  sharing  properties,  we  mean  that  some  of 
their  properties  are  induced  by  definitional  properties  of  the  class  in  question.  An  entity 
metaclass  is  a  'class'  of  entity  classes. 

The  property  categories  offered  by  RML  for  properties  with  subjects  that  are  entities 
are  as  follows: 

part  ~  the  value  is  a  non-null  entity  that  is  to  be  considered  a  component  of  the  subject. 
anodatloB  -  the  value  is  an  entity  that  can  change  over  time, 
aeepart  -  the  value  is  never  null. 

Invariant  -  the  value  is  an  assertion  that  is  true  of  the  subject. 

Initcond  -  the  value  is  an  assertion  that  is  true  at  the  time  the  object  becomes  an  instance  of 
the  class. 

flnalcond  ~  the  value  is  an  assertion  that  is  true  at  the  time  the  object  ceases  to  be  an  instance 
of  the  class. 

prodoccr  -  the  value  is  an  activity  which  produces  the  subject, 
consamer  -  the  value  is  an  activity  which  consumes  the  subject. 
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Bodtflcr  -  the  value  U  an  activity  that  modifies  the  subject. 

Activity  •bjscts 

Activities  are  used  to  represent  'happenings*  in  the  world.  An  activity  happens 
between  two  points  in  time,  called  its  start  and  end  times,  and  at  all  times  between  them  the 
activity  is  said  to  be  active.  An  activity  class  is  a  collection  of  activities  that  share  properties, 
which  characterize  participants  in  the  activity,  conditions  concerning  the  start,  end  and  active 
times,  as  well  as  component  activities.  Activity  metaclasses  characterize  collections  of  activity 
classes,  and  might  be  used,  for  example,  to  define  repetitive  or  intermittent  activities. 

The  property  categories  offered  by  RML  are  as  follows; 

Inpat  ~  the  value  is  an  entity  that  participates  in  the  activity  and  which  is  of  interest  at  the 
start  time  of  the  activity;  it  is  removed  by  this  activity  from  its  property  value  class. 

Mtpal  ••  the  value  is  an  entity  that  participates  in  the  activity  and  which  is  of  interest  at  the 
end  time  of  the  activity;  it  is  inserted  by  this  activity  into  the  property  value  class. 

control  -  the  value  is  an  entity  that  participates  in  the  activity  but  which  is  not  removed  by 
this  activity  from  its  property  value  class. 

prccoad  —  the  value  is  an  assertion  object  whose  truth  at  the  start  time  is  of  concern. 

postcond  ~  the  value  is  an  assertion  object  whose  truth  at  the  end  time  is  of  concern. 

actcond  -  an  assertion  which,  if  it  becomes  true  at  a  point  in  time,  causes  an  associated 
instance  of  the  activity  to  begin  at  that  point  in  time. 

stopcond  -  an  assertion  which,  if  it  becomes  true  at  a  point  in  time,  causes  the  associated 
activity  instance  to  stop  at  that  point  in  time. 

part  ••  the  value  is  an  activity  that  must  occur  (if  non-null)  in  order  for  the  subject  to  have 
occurred. 

AsKfUoB  objects 

RML  provides  an  assertion  sublanguage  in  which  the  user  can  formulate  assertions.  In 
this  expression  language,  the  predicates  are:  user-defined  assertion  class  names,  IN  (instance 
of),  ISA  (isa,  subclass  of,  q^ecialization  of),  =  (equality),  <  (time  ordering).  Terms  are 
formed  using  property  names  and  functions  PVAL  (property  selection),  RANGE  (definitional 
property  value  selection),  •  (factual  property  selection  with  omitted  time),  •  •  (abbreviation 
for  RANGE),  start,  stop  (special  time  points  for  activities).  Logical  connectives  and 
quantifiers  are:  or  ,  and,  not  orall ,  exists . 

Formulae  in  the  assertion  sublanguage  are  assertion  classes  in  RML.  An  assertion 
token  is  a  closed  formula  derived  from  an  assertion  class  by  binding  each  of  its  free  variables 
(represented  by  the  argnmenl  properties  and  perhaps  zero  in  number)  to  an  instance  of  the 
property  value  class  of  the  argument  properties.  Every  assertion  token  has  an  argument 
referring  to  the  time  when  the  assertion  is  supposed  to  hold,  so  a  token  represents  a  specific 
fact  that  is  true  at  a  specific  time.  An  assertion  class  is  a  collection  of  assertions  that  have 
something  in  common,  e.g.  the  respective  arguments  come  from  the  same  classes.  In  general. 
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an  assertion  class  is  a  collection  of  assertions  of  the  form  specified  by  the  assertion  class 
definition,  ijt.  which  has  the  arguments,  parts,  and  constraints  as  q>ecified  there. 

The  property  categories  offered  by  RML  are  as  follows: 

argoment  -  the  value  is  an  object  that  is  an  argument  (i«.  free  variable)  of  the  assertion. 

part  or  neccond  ~  the  value  is  an  assertion  that  is  true  when  the  subject  is  true. 

■nffcond  ~  assertions  giving  sufficient  conditions  for  being  an  instance  of  a  class. 

defn  ~  the  value  is  an  assertion  class,  every  instance  of  which  gives  a  necessary  and  sufficient 
condition  for  the  subject  being  true. 

comdralnt  -  the  value  is  an  assertion  e:q)ression  that  must  have  a  non*nuIl  value. 

When  an  assertion  class  appears  as  a  definitional  property  value,  then  the  property 
induction  principle  says  that,  if  the  factual  property  value  for  a  certain  instance  is  not  nothings 
then  it  must  be  an  instance  of  the  class,  which  is  a  true  statement. 

Examples 

Figure  2-1  is  a  description  of  the  entity  class  PATIENT,  giving  general  information 
about  patients  for  a  particular  ho^ital.  [1] 

PATIENT  in  PERSON_CLASS  with 
amodadoii  ward:  HOSPITAL_W ARD 
primary-physician:  PHYSICIAN 
consulting-physician:  PHYSICIAN 
prodocer  register  ADMIT_PATIENT(pat:  self  ) 

Inltcond  phys-ward?: 

primary-physician  •  specialty  =  ward 
or  consulting-physician  •  specialty  ==  ward 
modifier  transfer: 

TRANSFER(whom:  self  ^icw-ward  JIOSPITAL_WARD) 
connmer  release:  RELEASE(who:  self  ) 

Figure  2-1 


The  class  is  defined  to  be  an  instance  of  the  metaclass  PERSON_CLASS  and  has  a  number  of 
definitional  properties  consisting  of 

<attributc>  :  <valuc> 

pairs  and  grouped  into  property  categories  such  as  amoclatloB,  producer,  and  Inltcond. 


[1]  Our  examples  come  from  experience  with  a  medical  information  system  during  the  design 
of  a  Taxis  program  [DiMarco83].  A  requirements  language  was  not  used  during  the 
information  gathering  stage,  and  in  fact  one  of  the  conclusions  of  the  project  was  that  a 
language  such  as  RML  would  have  been  very  helpful:  understanding  the  problem  situation  was 
very  difficult  compared  to  writing  the  Taxis  program. 
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The  properties  of  PATIENT  relate  each  patient  to  a  ward  and  two  physicians,  one 
primary  and  the  other  consulting.  Patients  are  'created'  through  an  ADMIT_PATIENT 
activity,  modified  through  a  TRANSFER  activity  and  removed  from  the  class  of  patients 
through  a  RELEASE  activity.  When  a  patient  is  first  created,  it  must  be  the  case  that  if  the 
ward  to  which  a  patient  is  assigned  is  not  the  q>ecialty  of  his/her  primary  (care)  physician, 
then  it  must  be  the  specialty  of  the  consulting  physician. 

In  Figure  2-2,  we  present  a  definition  of  the  activity  class  ADMIT_PATIENT.  It 
consists  of  one  input  property,  a  person,  and  one  output  property,  a  patient;  also,  it  has  three 
control  properties,  a  ward  and  two  physicians.  The  activity  is  triggered  by  instances  of  the 
assertion  class,  ARRIVAL,  which  is  instantiated  each  time  a  person  arrives  at  the  hospital  for 
admission. 

ADMIT_PATIENT  also  includes  two  preconditions  (already-in?  and  room-left?)  and  a 
postcondition  (admitted?)  that  must  be  true  before  and  after  the  activity,  respectively.  The 
preconditions  assert  that  the  person  must  not  be  already  a  patient  of  the  hospital,  and  also 
that  the  number  of  patients  (PATIENT  •  cardinality)  is  less  than  the  hospital  capacity 
(PATIENT_MAX).  The  postcondition  asserts  that  the  person  has  indeed  been  admitted  once 
the  ADMIT_PATIENT  activity  is  over. 

ADMIT_PATIENT  in  ACTIVITY_CLASS  wi/h 
Inpot  p:  PERSON 
control  w:  HOSPITAL_WARD 

phys,  consulting-phys:  PHYSICIAN 
ootpat  pt:  PATIENT 
tiiggercd-bj  al:  ARRIVAL(who:  p) 
precondition  already-in?:  nor  IN(p,  PATIENT) 
room-left?: 

PATIENT  •cardinaUty  <  PATIENT_MAX 
postcondition  admitted?:  IN_HOSPITAL(who:  p) 
part  check-id:  CHECK_ID(p) 

put:  CHOOSE_WARD(w,phys,con8ulting-phys) 
increment:  INCREMENT^ATIENTo  cardinality) 
urinalysis:  PERFORM_URINALYSIS(who:  p) 
blood-count:  PERFORM_BLOOD_COUNT(who:  p) 
blood-pressure:  PERFORM_BLOOD_PRESSURE(who:  p) 
temp:  TAKE_TEMP(of-whom:  p) 


Figure  2-2 


Finally,  the  'body'  of  ADMIT_PATIENT  is  defined  by  several  part  properties  which 
specify  the  components  of  an  ADMIT_PATIENT  activity.  The  components  involve  checking 
the  person’s  ID,  choosing  a  ward  and  assigning  a  primary  care  and  a  consulting  physician,  and 
incrementing  the  cardinality  property  of  PATIENT;  also,  some  tests  are  performed  (urinalysis, 
blood-count,  blood-pressure,  and  temperature).  The  postcondition  states  that  the  result  of  the 
activity  includes  asserting  that  the  Input,  p,  becomes  a  patient  in  the  hospital.  There  are 
several  features  of  RML  that  need  explaining  in  the  examples.  Assertion  classes  in  RML  can 
be  named  classes,  c.g.  IN_HOSPITAL,  or  inline  expressions,  e.g.  the  property  value  of  the 
tnltcond  property  in  Figure  2-1.  Inline  assertion  expressions  are  discussed  near  the  end  of  this 
chapter. 
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The  special  symbol  self  acts  as  a  'typical*  instance  of  the  class  being  defined,  so  that 
wherever  it  appears,  the  expression  can  be  t^en  as  applicable  to  any  instance  of  the  class. 

The  *dot*  (•)  notation  is  used  for  factual  property  selection.  It  is  an  abbreviation  for 
property  value  selection  in  general,  applying  at  any  'typical*  time.  IN(x,y)  is  similarly  an 
abbreviation  for  IN(x,y,z),  where  the  third  argument,  representing  the  time  when  x  is  an 
instance  of  y,  is  omitted,  meaning  that  x  is  in  y  whenever  necessary,  as  dictated  by  the 
property  category. 

One  can  also  refer  to  the  definitional  property  value  by  the  •  •  selector.  If  (C4  is 
a  definitional  property,  then  Co  *1=0. 

After  a  definitional  property  value,  one  may  place  bindings,  which  are  just  a  set  of 
equality  constraints  that  are  more  convenient  to  represent  in  parentheses  rather  than 
separately  as  ^)ecial  kinds  of  constraints.  A  binding  expression  consists  of  one  or  more 
<  attribute>  :<  value>  pairs,  the  first  being  an  attribute  of  the  invoked  class  and  the  second 
being  an  expression  for  the  object  that  is  to  be  bound  to  it.  We  omit  the  attribute  wherever  it 
is  obvious  what  it  is  supposed  to  be,  e.g.  when  there  is  only  one  attribute  for  the  invoked  class 
or  for  built-in  assertions  such  as  IN(x,y),  where  it  is  always  understood  that  x  is  the  object 
that  is  an  instance  of  y,  not  the  other  way  around. 

We  present  an  example  of  an  assertion  class  in  Figure  2-3  to  underscore  the  uniform 
treatment  of  the  object  categories.  The  assertion  class  IN_HOSPITAL  has  one  argument,  a 
patient,  and  asserts  through  its  part  property  that  the  person  is  now  physically  present  at  the 
hospital. 

IN_HOSPITAL  in  ASSERTION_CLASS  with 
argument  p:  PERSON 
part  patient?:  IN(p,PATIENT) 

present?:  PHYSICALLY_PRESENT(who:  p) 

Figure  2-3 


We  next  give  a  definition  of  the  metaclass  PERSON_CLASS,  in  Figure  2-4.  As  stated 
earlier,  PATIENT  is  entitled  to  a  cardinality  property  only  because  it  is  an  instance  of  this 
metaclass.  Note  that  ENTITY_METACLASS  is  a  built-in  metametaclass  that  has  all  entity 
metaclasses  as  instances. 

PERSON.CLASS  in  ENTTTY.METACLASS  with 
asaoclatloQ  average-age:  AGE_VALUE 
cardinality:  NUMBER 


Figure  2-4 


To  Nippon  the  geiuraluation  abstraction  mechanism,  a  new  relationship,  subclass^  is 
defined  which  can  be  declared  between  two  classes  or  two  metaclasses.  For  example,  suppose 
PERSON  has  been  defined  as  shown  in  Figure  2-S.  (Note:  The  part  properties  of  an  entity 
class  instance  do  not  change  values,  while  the  association  properties  do.)  Then,  changing  the 
first  line  of  the  definition  of  PATIENT  (Figure  2-1)  to 

PATIENT  In  PERSON_CLASS  isa  PERSON 

makes  PATIENT  a  subclass  or  special  hat  Ion  of  PERSON  and  PERSON  a  generalization  of 
PATIENT. 

PERSON  in  PERSON_CLASS  with 
part  name:  PERSON_NAME 
sin:  SOCIAL_INSURANCE_# 
ohip:  ONTAWO_INS_i^‘ 
assoclatloo  address:  ADDRESS 
age:  AGE_VALUE 


Figure  2-S 


What  does  it  mean  to  say  that  PATIENT  is  a  specialization  of  PERSON?  Well,  for 
one  thing  we  expect  that  every  instance  of  PATIENT  is,  under  all  circumstances,  also  an 
instance  of  PERSON.  Indeed,  the  semantics  of  becoming  an  instance  of  a  class  includes 
becoming  an  instance  of  all  of  the  generalizations  of  the  class.  Conversely,  when  an  object 
ceases  to  be  an  instance  of  a  class,  it  also  ceases  to  be  an  instance  of  its  specializations. 

Another  aspect  of  specialization  concerns  the  definitional  properties  of  the  two  classes 
involved.  All  definitional  properties  of  PERSON  are  inherited  by  PATIENT;  so,  by  virtue  of 
being  declared  a  specialization  of  PERSON,  PATIENT  has,  in  addition  to  the  properties 
specified  in  Figure  2-1,  also  a  name,  a  social  insurance  number,  an  address,  etc. 

Property  inheritance  allows  for  economy  of  expression  in  a  specification  because  a 
definitional  property  need  only  be  mentioned  once  for  the  most  general  class  to  which  it  is 
applicable.  Inheritance  also  serves  as  a  memory  aid,  since  knowing  that  a  class  is  a  subclass  of 
another  allows  one  to  concentrate  on  the  additional  information  needed  to  describe  the 
subclass. 
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CHILD  In  PERSON.CLASS  isa  PERSON  with 
UMcIntloii  age:  CHILD_AGE_VALUE 
guardian:  PERSON 
Invariant  guardian* age  >  30 

SURGICAL_PATIENT  in  PERSON_CLASS  isa  PATIENT  with 
anoclatlon  blood-type:  BLOOD  TYPE 
surgery:  SURGERY.TTPE 


TRANSPLANT  SURGERY_PATIENT 

ln”PERSON_CLASS  isa  SURGICAL_PATIENT  with 
aooclatlon  donor:  PERSON 


CHILD_PATIENT  in  PERSON_CLASS  isa  CHILD,  PATIENT  with 
anoclatlon  nurse:  NURSE 


Figure  2-6 


To  illustrate  the  importance  of  generalization,  suppose  we  have  already  defined  the 
class  PERSON  and  its  specialization  PATIENT.  A  number  of  other  entities  are  also  relevant 
for  our  ho^ital  example.  CHILD  q>ecializes  PERSON  by  restricting  its  age  property  to  allow 
only  values  in  CHILD_AGE_VALUE.  SURGICAL_PATIENT  as  weU  as 
TRANSPLANT_SUROERY_PATIENT  are  specializations  of  PATIENT.  CHILD_PATIENT 
gives  an  example  of  a  class  that  has  more  than  one  immediate  generalization.  Figure  2-6 
includes  the  definitions  of  all  these  entity  classes  while  Figure  2-7  summarizes  the  subclass 
relation  for  the  entity  classes  defined  so  far. 

Specialization  opens  the  door  to  a  form  of  stepwise  refinement  that  is  based  on  the 
introduction  of  detail  for  special  cases.  Moreover,  this  form  of  refinement  is  not  applicable 
only  to  entity  classes.  Consider,  for  example,  some  specializations  of  ADMIT_PATIENT,  as 
shown  in  Figure  2-8. 
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(The  classes  in  parentheses  have  not  been  defined.) 

Figure  2-7 


The  first,  ADMIT_CHILD_PATIENT,  simply  assigns  a  nurse  to  the  child  patient  in  addition 
to  all  the  things  done  for  other  patients.  The  second  specializes  ADMIT_PATIENT  for 
siirgical  patients  where  a  blood  test  is  done  for  possible  transfusion. 
ADMIT_SURGICAL_CHILD_PATIENT,  the  third,  is  a  specialization  of  the  previous  two 
activities  and  therefore  inherits  all  their  definitional  properties;  in  addition,  it  has  a 
definitional  property  of  its  own  which  obtains  permission  for  surgery  from  the  child’s 
guardian. 
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ADMIT_CHILD_PATIENT  in  ACTIVITY_CLASS  isa  ADMIT_PATIENT  with 
Input  p:  CHILD 
control  n:  NURSE 
output  pt:  CHILD_PATIENT 
part  find-nurse:  FIND  NURSE(n,w) 
admit:  INSERT(P,CHILD_PATIENT) 


ADMIT  SURGICAL_PATIENT  in  ACTIVITY  CLASS  isa  ADMIT  PATIENT  with 
output  pt:  SURGICAL_PATIENT 
trlggcrcd-by  al:  ARRIVAL(of-whom:  p) 

and  SURGERY  NEEDED(for-whom:  p) 
part  blood-typing:  PERFORM_BLOOD_TYPING 


ADMIT  SURGICAL  CHILD_PATIENT  in  ACTIVITY  CLASS 

isa  ADMIT_CfflLD_PATIENT.  ADMIT_SURGICAL_PATIENT  with 
part  obtain-permission: 

OBTAIN_PERMISSION(for:p,  from^o  guardian) 

Figure  2-8 


Note  that  redefinitions  of  definitional  properties  must  be  consistent  with  the 
properties  they  replace.  For  example,  the  value  of  the  age  property  of  child, 
CHILD_AGE_VALUE,  must  be  a  specialization  of  AGE_VALUE  (Figures  2-S  and  2-6). 
Similarly,  the  redefinitions  of  properties  such  as  p  and  pt  in  ADMIT_CHILD_PATIENT  are 
all  consistent  with  the  properties  of  ADMIT_PATIENT  they  replace  (Figures  2-2  and  2-8). 
An  interesting  application  of  this  consistency  rule  involves  properties  whose  value  is  an 
assertion  class  such  as  the  al  property  of  ADMIT_PATffiNT  (Figure  2-2).  For 
ADMIT_PATIENT  the  value  of  al  is  the  assertion  ARRlVAL(p),  while  for 
ADMIT  SURGICAL_PATIENT  (Figure  2-8)  the  value  of  al  is  the  stronger  assertion 
ARRIVAL(p)  and  SURGERY_NEEDED(p). 

Specialization  can  also  be  used  to  structure  assertion  class  definitions.  The 
IN_HOSPITAL  assertion  class,  for  instance,  can  be  specialized  by  specializing  its  arguments, 
by  adding  conjuncts  (parts),  or  even  by  redefining  some  of  its  parts  by  giving  the  inherited 
arguments  a  more  q>ecialized  definitional  property  value.  Thus,  for  child  patients, 
IN_HOSPITAL  might  be  specialized  (see  Figure  2-9)  to  check  that  the  patient  is  in  a  ward 
accompanied  by  a  nurse. 

ASSERTION_CLASS  CHILD_IN_HOSPITAL  isa  IN_HOSPITAL  with 
argument  p:  CHILD 
part  in-ward?:  IN  WARD(who:p) 
with-nurse?:  WITH_NURSE(cp7)) 


Figure  2-9 


2^.1 1«  HlcnrchlM  for  meUclMcs  aod  metamcfaclaweo 

There  ore  also  some  built-in  objects,  some  of  them  residing  at  levels  other  than  these 
three.  We  now  mention  them;  see  Figure  2-10. 

First,  there  is  the  special  class,  TOKEN,  which  contains  all  tokens.  Second,  there  is 
the  metaclass,  CLASS,  containing  all  classes.  In  addition,  there  is  the  metametaclass, 
METACLASS,  which  contains  all  metaclasses.  There  are  also  three  more  built-in  classes, 
EN'nTY_TOKEN,  ACTIVITY_TOKEN,  ASSERTION_TOKEN;  and  three  more  buUt-in 
metaclasses,  ENTTTY.CLASS,  ACTIVrrY_CLASS,  ASSERTION_CLASS.  Off  to  the  side, 
we  put  the  (only  other)  built-in  objects,  which  are: 

OBJECT  -  which  has  as  instances  all  objects  (including  itself) 

ANY_CLASS  "  which  has  as  instances  all  objects  except  tokens 
ANY_METACLASS  -  which  has  as  instances  all  objects  except  tokens  and  classes. 

Metaclasses  (and  metametaclasses)  are  also  organized  into  q>ecialization  hierarchies,  as 
suggested  in  Figure  2-10. 


oninr'T 


ENTITY  ACTIVITY  ASSERTION  ^  METACLASS 

CLASS  CLASS  CLASS 


BuiltAn  objects 
Figure  2-10 

2  J  More  on  Aaertloiis 

We  have  argued  that  constraints  are  indispensable  if  we  are  to  provide  proper 
specifications.  RML  provides  a  number  of  predicates  and  functions  which  appear  to  be 
essential  or  commonly  useful  for  making  some  assertions.  Included  in  this  list  are  the 
following. 
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IN(x,y^),  which  asserts  object  x  is  an  instance  of  y  at  time  z 
=  ,  the  identity  predicate; 

PVAL(x,y^),  which  yields  the  y  factual  property  value  of  x  at  time  z. 

RANGE(x,y),  which  yields  the  y  definitional  property  of  x. 

START(x),  END(x),  which  yield  the  start  and  stop  times  of  activity  x. 

DURING(x,y),  which  asserts  that  activity  x  occurred  entirely  while 
activity  y  was  occurring; 

NEXT(x,y),  which  asserts  activity  y  starts  exactly  when  x  8toi»; 

BEFORE(x,y),  which  asserts  activity  x  completes  before  y  starts; 

SAMEBEGIN(x,y),  which  asserts  activity  x  begins  at  the  same  time 
as  activity  y,  but  completes  before  y; 


In  addition  to  these,  the  user  will  likely  require  more  complex  assertions  and  may  form 
expressions  as  desired  from  user-  and  RML-provided  predicates  and  the  RML  logical 
connectives  (or ,  and,  not ,  implies  ,if  f 

As  with  entities  and  activities,  we  contend  that  in  cases  where  the  requirements 
become  very  large,  there  will  be  a  need  to  organize  the  collection  of  assertions  themselves.  It 
is  hoped  that  the  organization  of  assertions  provides  an  indexing  whereby  the  ^ecifier  can  (1) 
check  if  closely  related  assertions  have  been  used  before  and  thus  specify  new  assertions 
incrementally,  (2)  if  some  assertion  is  to  change,  obtain  an  indication  of  what  other  assertions 
one  might  have  to  reconsider  in  light  of  this  change. 

Since  uniformity  is  one  of  our  guiding  principles  in  designing  RML,  we  have  chosen  to 
model  assertions  as  objects  organized  into  classes  as  well.  In  this  case,  an  assertion  class  is  to 
be  interpreted  as  a  predicate,  while  instances  of  this  class  reprint  true  propositions  obtained 
by  instantiating  the  free  variables  of  the  predicate.  In  analogy  with  entity  classes,  an  assertion 
class  will  have  zero  or  more  attributes/properties,  which  in  this  case  correspond  to  the  free 
variables,  and  these  variables  will  be  typed  by  the  usual  method  of  definitional  properties. 

For  example,  the  assertion  LIKE  might  be  modeled  by  the  class 

LIKE  in  ASSERTION.CLASS  with 
arguments 
x:  PERSON 
y:  PERSON 


and  at  any  instance  of  time,  this  class  contains  tokens  which  have  as  pairs  of  attributes  two 
persons  such  that  one  likes  the  other. 
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Sometimes,  we  will  want  to  relate  this  assertion  with  others,  as  was  done  for  activities 
and  entities.  Properties  with  assertion  values  can  be  used  for  this  purpose,  with  the  continued 
understanding  that  if  the  attribute  value  is  not  null,  the  corresponding  assertion  is  true.  For 
example,  we  could  expand  on  the  LIKE  predicate  as  follows: 

LIKE  in  ASSERTION_CLASS  with 
arguments 
x:  PERSON 
y;  PERSON 
parts 

c:  RICH(p7) 

d:  UNEQUAL(argl3JCX  ,  argZ^sex) 


Once  again,  property  categories  can  be  used  to  impose  a  certain  interpretation  on  the 
properties.  Thus,  if  in  the  above  parts  is  replaced  by  necessary  then  the  attribute  values 
cannot  be  null  and  hence  both  must  be  true  whenever  a  proposition  is  true.  This  clearly 
accommodates  'necessary  conditions'  for  a  predicate.  Alternatively,  we  can  use  the  same 
constraint  mechanisms  as  for  activities  or  entities  to  further  elaborate  on  the  meaning  of  the 
assertion.  For  example,  if  we  wish  to  say  that  x  likes  y  if  either  y  is  rich  or  x  and  y  are  of 
opposite  sex,  then  this  could  have  been  accomplished  by  the  following: 

LIKE  in  ASSERTION_CLASS  with 
arguments 
x:  PERSON 
y;  PERSON 
parts 

c:  RICH(p7) 

d:  UNEQUAL(argl3xcx  ,  argZyxcx) 

necessary 

a:  EITHEROF(arglr,  arg2d) 


where  EITHEROF  has  been  defined  to  ensure  that  one  its  two  arguments  is  not  null.  Finally, 
we  may  want  to  relate  assertions  with  activity  types,  such  as  activities  which  can  alter  the 
truth  value  of  a  proposition. 

As  with  other  classes,  we  can  now  organize  assertions  into  IS-A  hierarchies.  This  is 
intended  to,  among  other  things,  facilitate  the  process  of  q>ecializing  consistently  other 
classes  ix.,  within  the  rules  of  the  IS-A  postulates.  This  means  that  if  P  is  an  assertion 
subclass  of  Q,  then  P  must  be  more  'restrictive'  than  Q  and  all  instances  of  P  must  be 
instances  of  Q. 

Specialization  proceeds  with  assertion  classes  in  the  same  manner  as  with  entity  and 
activity  classes.  Thus,  having  defined  the  class  LIKES  as  above,  we  can  then  define 

LOVE  isa  LIKE 

and  LOVE  will  inherit  the  properties  of  LIKE.  As  for  entity  and  activities,  the  more 
specialized  assertion  can  have  additional  properties  and  more  specialized  property  values  for 
inherited  properties.  In  particular,  the  more  specialized  assertion  can  have  more  arguments, 
more  parts,  and  more  constraints,  and  inherited  arguments  may  come  from  a  more  restricted 
class. 
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Note  that  if  P  isa  Q,  then  P  logically  implies  Q;  however,  the  converse  does  not  hold. 

Quantified  variables  do  not  appear  as  properties,  but  are  only  embedded  in  inline 
expressions.  Thus,  organization  of  assertions  does  not  take  into  account  the  interpretation  of 
quantified  formulae. 
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CHAPTER  3 

FORMAL  DEFINITION  OF  RML 


In  the  first  two  sections  of  this  chapter,  we  discuss  the  purpose  of  the  formalization 
and  some  issues  concerning  the  choice  of  underlying  formalism.  Then  the  formal  definition  of 
RML  is  given,  in  terms  of  a  translation  from  RML  into  a  First-Order  Logic.  The  First-Order 
Logic,  which  we  call  here  L,  is  defined  as  the  target  of  the  translation,  and  then  a  formal 
mapping  is  given  from  RML  to  L. 

Thus,  an  RML  specification  is  equivalent  to  a  set  of  axioms  (a  theory)  in  L.  These 

include: 

1.  The  basic  axioms  (property  induction  and  isa  constraints)  of  RML. 

2.  Axioms  for  the  'instance*  and  'isa*  declarations  in  the  first  line  of  an  object  definition. 

3.  For  each  property,  an  axiom  that  associates  the  subject  and  value  and  indicates  the 
property  category. 

4.  For  each  property  category,  an  axiom  defining  the  category. 

5.  RML  assertions,  which  translate  directly  into  L. 

6.  Axioms  for  built-in  objects. 

3.1  Reasons  for  Formalization 

There  are  several  reasons  that  compel  us  to  present  a  formal  definition  of  the 
semantics  of  RML.  To  begin  with,  the  process  of  giving  a  formal  definition  to  any  uovel 
product  such  as  an  artificial  language  for  programming  or  requirements  forces  us  to  consider 
in  detail  the  precise  meaning  of  its  constructs.  This  often  leads  to  the  discovery  of 
ambiguities,  and  it  may  even  result  in  modifications  to  the  language  whenever  difficulties  in 
the  formalization  or  obvious  asymmetries  arise. 

Second,  given  a  requirements  specification,  there  is  a  number  of  questions  that  one 
often  wishes  to  have  answered,  including: 

•  Is  the  ^>ecification  self -contradictory? 

-  Does  the  specification  allow  a  certain  situation  to  arise? 

A  formal  semantics  (yrovides  a  domain  where  the  definition  of  such  terms  as  'consistency*  can 
be  given,  and  hence  sets  a  standard  against  which  to  judge  the  correctness  of  any  computer 
tools  that  purport  to  assist  the  user  in  answering  the  above  questions. 
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The  final  reason  we  mention  here  is  that  the  formal  definition  of  the  language  can  be 
used  by  the  users  and  readers  of  the  language  as  the  final  arbiter  in  cases  where  there  is 
disagreement  as  to  the  exact  meaning  of  some  specification. 

3 J  Some  Isiacs  In  the  selection  of  a  formal  semantics 

In  selecting  a  method  for  expressing  the  semantics  of  RML  we  have  considered  a 
number  of  issues. 

To  begin  with,  RML  is  a  specification  language,  whose  intended  use  is  to  place 
constraints  on  the  potential  systems  implementations,  with  minimal  possible  interference  with 
the  task  of  the  implementor;  in  RML  one  has  the  ability  to  be  as  precise  as  desired,  but  also 
to  be  vague,  leaving  implementation  details  unspecified. 

A  second  important  characteristic  of  requirements  languages  is  that  they  are  almost 
always  used  to  model  or  describe  dynamic,  as  opposed  to  static,  enterprises.  This  makes  the 
notions  of  events  and  changes,  together  with  some  idea  of  time,  of  central  importance  to  the 
language,  and  makes  traditional  pure  Predicate  Calculus  inappropriate. 

Accepting  time  or  change  as  a  basic  fact,  one  is  still  left  with  a  number  of  questions 
about  the  nature  of  objects  and  events  that  may  occur.  Is  time  viewed  as  a  sequence  of  static 
snapshots  so  that  one  can  always  ask  about  "the  next  state*?  Tied  to  this  is  the  existence  of  a 
default  assumption  (a  general  'frame  axiom*)  that  there  are  no  changes  in  the  domain  of 
interest  unless  some  specified  event  has  caused  them.  In  a  requirements  specification 
language,  it  seems  appropriate  that  the  designer  be  required  to  expend  extra  effort  in  order 
to  state  such  a  condition  as  a  constraint,  since  it  severely  limits  certain  implementations.  For 
this  reason,  we  have  chosen  not  to  use  one  of  the  traditional  programming  logics,  or  temporal 
logics  for  programming  systems  ([Ben-Ari  81],  [deCastilho  82]). 

Another  issue  is  whether  the  world  is  viewed  as  *non>deterministic*  or  'non¬ 
sequential*.  Given  a  desired  specification,  is  there  the  possibility  that  there  may  be  several 
changes  that  might  occur  in  one  situation,  yet  it  is  not  known  which  will  occur?  Also,  may 
several  changes  occur  in  parallel,  or  must  they  be  'serialized*  ?  We  believe  that  a 
requirements  language  has  to  have  both  of  these  la^  two  freedoms  if  it  is  to  be  useful  in  a 
wide  range  of  situations  (e.g.,  allowing  concurrency  in  implementation). 

Defining  a  new  notion  involves  presenting  an  explanation  in  some  language  with 
previously  well  understood  concepts.  Probably  the  best  understood  such  language  is  that  of 
mathematics.  A  formal  definition  involves  the  use  of  a  language  which  can  be  described  using 
syntactic  criteria,  i.e.,  based  on  the  'form*  of  the  terms,  and  one  advantage  of  using  a  formal 
language  is  that  computers  are  adept  at  manipulating  formal  languages. 

Logics  are  formal  systems  which  incorporate  the  notions  of  'assertion*  together  with 
formal  rules  of  reasoning,  and  whose  semantics  is  clearly  specified  using  some  mathematics. 
From  our  point  of  view  it  appears  advantageous  to  use  some  logic  as  the  language  in  which  the 
meaning  of  RML  is  expressed  because  (i)  certain  'assertions*  already  form  part  of  RML,  (ii) 
logics  come  ready-made  with  notions  such  as  'consistency*  and  'deduction”,  which  are  relevant 
for  a  requirements  language,  (iii)  properties  of  interest  to  us  have  usually  been  explored  by 
previous  investigators,  in  contrast  to  some  novel  mathematical  structure  we  might  invent. 
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Temporal  or  tense  logics  (e.g.,  [Rescher  71]),  as  derived  from  modal  logics,  are 
intended  to  highlight  timt  as  a  chief  issue  to  be  investigated,  but  in  the  process  they  introduce 
new  higher-level  operators,  requiring  new  axiomatizations,  and  new  mathematical  semantics  in 
the  form  of  models.  Since  these  higher-level  logics  are  less  well  understood,  it  seems 
advantageous  to  stick  to  the  FOL  framework,  especially  since  there  has  been  considerable 
work  on  automatic  deduction  in  this  context.  However,  there  is  nothing  to  prevent  us  from 
offering  the  abbreviations  proposed  in  temporal  logics  (c.g.,  a  default  NOW  time, 
abbreviations  for  'P  until  O',  etc.)  to  users  of  RML.  For  similar  reasons  we  will  also  avoid  the 
intensional  logic  of  Montague  ([Montague  73]),  which  is  intended  to  deal  with  problems  of 
concepts  with  changing  denotations  (e.g.,  temperature). 

The  traditional  way  of  extending  FOL  to  deal  with  change  is  through  the  situational 
calculus  ([McCarthy  68]),  where  an  extra  argument  is  added  to  all  time-dependent  functions 
and  predicates,  while  events  are  specified  through  predicates  on  the  situations  they  'connect*. 
Within  this  general  framework,  several  alternatives  arise  as  to  the  nature  of  the  'situations'. 

The  weakest  assumption,  one  adopted  in  programming  logics  and  papers  like 
[deCastilho  82]  and  [McCarthy  68],  is  that  there  is  no  constraint  on  the  ordering  of  situations. 
This,  however,  is  obtained  by  modeling  events  as  'state  changes*  (sets  of  pairs  of  states).  This 
does  not  allow  one  to  talk  about  what  may  happen  while  an  event  is  occurring,  and  it 
eliminates  discussions  of  parallelism  and  synchronization.  It  also  makes  it  difficult  to  talk 
about  durations  of  event  occurrences. 

It  is  also  possible  to  consider  time  as  a  partial  order,  as  done  in  [McDermott  81], 
[McCawley  81],  and  tense  logics,  with  several  possible  futures  such  that  each  is  a  total  order. 
This  is  advantageous  for  planning  actions,  revising  beliefs  or  representing  the  meaning  of 
English  sentences  referring  to  future  possibility,  but  seems  superfluous  baggage  for  our 
purposes,  since  the  specification  is  taken  to  be  a  'God’s  eye-view*  of  the  situation,  and  we 
are  not  concerned  with  providing  a  formal  system  in  which  one  can  reason  on  how  to  achieve 
certain  goab. 

We  are  thus  led  to  a  linear  view  of  time  in  which  situations  are  totally  ordered. 
Since  we  are  concerned  with  events  which  have  durations  and  may  be  repetitive,  it  seems  that 
it  is  best  to  associate  time  intervals  with  the  occurrence  of  events.  This  has  led  Allen[81]  to 
explore  the  possibility  of  making  time  periods  be  situational  indices.  We  feel,  however,  that 
these  can  be  described  within  the  ordinary  time-point  framework.  In  this  way,  we  avoid  some 
of  the  complexities  of  properly  axiomatizing,  within  the  same  framework,  both  time  periods 
and  points,  as  well  as  some  problems  such  as  defining  the  meaning  of  an  existentially 
quantified  assertion  over  some  period  of  time. 

3  J  The  Target  Language  L 

3J.1  An  Augmented  Many-nrtcd  First-Order  Logic 

It  would  be  very  helpful  to  be  able  to  structure  the  domain  of  discourse  in  a  way  that 
mirrored  the  division  of  RML  objects  into  tokens,  classes,  metaclasscs,  and  into  entity,  activity 
and  assertion  object  categories.  Many-sorted  First-Order  Logics  (MSFOLs)  allow  nonlogical 
symbols  to  be  partitioned  into  disjoint  'sorts';  a  MSFOL  is  equivalent  to  a  standard  FOL  but 
abbreviated  by  encoding  information  about  the  arguments  of  predicates  in  'sort  signatures*. 
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To  allow  us  to  talk  about  entity-tokens,  entity-classes,  etc.,  it  would  be  convenient  to 
have  sorts  that  overlap,  ijc.  to  have  intersection  and  union  of  sorts  and  'subsorts'. 
Augmenting  the  MSFOL  in  this  way  will  make  our  presentation  clearer  and  more  concise.  A 
normal  MSFOL  can  be  obtained  from  it  by  choosing  the  disjoint  intersections  of  sorts  as  the 
true  sorts,  thus  enumerating  all  of  the  special  cases. 

A  MSFOL  has  a  set  of  sorts,  a,  and  a  potentially  infinite  collection  of  variable 
symbols,  each  belonging  to  one  of  the  sorts. 

Each  predicate  of  such  a  language  is  associated  with  one  or  more  sort  signatures, 
which  for  an  n-ary  predicate  are  n-ary  vectors  of  elements  of  a.  [1]  Intuitively,  each  sort 
signature  specifies  the  sort  of  the  corresponding  arguments  for  the  predicate;  if  multiple  sort 
signatures  are  given  for  a  predicate,  each  occurrence  of  the  predicate  must  match  one  of  the 
signatures. 

Similarly,  each  n-ary  function  symbol  is  associated  with  one  or  more  sort  signatures, 
which  are  (n+l)-vectors  of  o  and  specify  that  permitted  sorts  for  the  arguments  of  the 
function  as  well  as  the  sort  of  the  function  value. 

Next,  a  MSFOL  has  the  standard  formation  rules,  using  as  logical  symbols:  A,  V, ^ , 
o ,  V,  and  B . 

The  standard  notions  of  interpretation,  theory  and  model  apply  to  such  a  language. 

We  extend  this  language  with  the  special  binary  predicate  -,  and  its  complement  # , 
to  get  an  FOL  with  identity.  In  writing  assertions  we  will  assume  that  all  free  variables  are 
universally  quantified,  and  whenever  a  symbol  could  be  either  a  constant  or  a  variable,  it  will 
be  a  variable  unless  expressly  stated  that  it  is  a  constant. 

The  set  a  of  sorts  contains  the  following  elements: 

T  symbols  representing  tokens 
C  symbols  representing  classes 
M  symbols  representing  metaclasses 
1  symbols  representing  property  names  (attribute  identifier) 

S  symbols  representing  time  points  (states,  situations) 


T,  C,  M  are  classification  sorts,  and  are  mutually  exclusive.  We  will  gradually  introduce 
additional  sorts,  called  category  sorts,  for  entity,  activity,  and  assertion  objects;  these  will  be 
'subsortsT  of  the  classification  sorts. 


[1]  By  renaming  predicate  symbols,  this  could  be  restricted  to  a  single  sort  for  each  predicate, 
but  for  convenience  we  adopt  this  view. 
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3  J  J  Time  Points 


Elements  of  sort  S  are  linearly  ordered  by  the  predicates  ^  g  (before)  and  =g  (equality 
for  time)  of  sort  <SJS>.  For  convenience,  strict  precedence  <g  for  time  is  defined  in  the 
obvious  way.  (Hereafter,  we  will  omit  the  subscript  since  the  sort  of  the  equality  can  always 
be  determined  from  the  context).  There  is  a  constant  symbol,  +»  ,  of  sort  S,  which  may  be 
thought  of  as  'never*,  a  time  point  that  is  never  reached.  The  following  axioms  present  the 
desired  properties  of  time. 

(si  s  s2)  A  (s2  s  s3)  =>  (si  i  s3) 

(si  s  52)  A  (52  ^  si)  =>  (si  =  82) 

(si  s  82)  V  (82  s  si) 

(si  <  s2)  <=>  (si  s  s2)  A  (si  #  s2) 

s  < 

Vs,t  3  s’  s<  s’<  t  (time  is  dense) 


3J J  Basic  Framework  Predicates  and  Functions 

In  formalizing  the  Basic  Framework,  the  following  predicate  and  function  symbols  arc 
used.  (Note  that  the  sort  of  a  predicate  gives  the  sort  of  each  argument;  For  example,  for 
'In*  the  arguments  are  either  a  token,  a  class,  and  a  time,  or  alternatively,  a  class,  a  metaclass, 
and  a  time.  For  a  function,  the  sorts  of  the  arguments  are  given,  and  then,  to  the  right  of  a 
semicolon,  the  sort  of  the  value  of  the  function  is  given.  For  example,  for  fpv,  the  first 
argument  is  a  token  or  a  class,  the  second  argument  is  an  attribute,  and  the  third  argument  is 
a  time;  the  sort  symbols  following  the  semicolon  indicate  that  the  function  returns  a  value  of 
sort  token  or  class.) 

In(x,C,s)  X  is  an  instance  of  C  at  s. 

Sort:  <T,C3>,  <C,M,S> 

Isa(C  J3)  C  is  a  subclass  of  D  (C  ISA  D). 

Sort:  <  C,C>  ,  <  M,M> 

fpv(x44)  The  i  factual  property  value  of  x  at  s. 

Sort:  <  TU  C,  I,  S  ;TU  C> 

dpv  (C4)  The  i  definitional  property  value  of  C. 

Sort:  <  CU  M,  I  ;  CU  M> 


Note  that  Isa  and  dpv  are  time-independent. 
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33.4  NoU  value 


We  add  to  the  language  a  constant  symbol,  J_ ,  belonging  to  all  sorts  except  S  and  1. 
The  null  value  is  not  an  instance  of  any  class(metaclass)  and  itself  has  no  instances. 

■  Ind  fCA)  A  ■  In(x J.  fi) 


The  value  of  every  factual  and  definitional  property  of  j.  is  JL  ;  in  other  words,  J.  has  no 
properties. 

fpvCL  4,s)=X  A  dpvd  4)=X 


33^  Basle  Framework  Axioms 

The  property  induction  constraint  is  stated  as  follows: 

[dpv(C4)=D  A  D#  X  A  fpv(x4,t)=y  A  In(x,C,t)l  =>  [y=j.  V  In(yX>,t)] 

The  extensional  ISA  constraint  states  that  every  instance  of  the  subclass  is  in  the 
superclass. 

Isa(C  A  In(x,C,t)  =>  In(x4>,t) 


The  intentional  ISA  constraint  states  that  the  definitional  properties  of  the  superclass 
are  inherited  by  the  subclass. 


(Isa(C4>)  A  dpv(D4)=F  A  X  )  ^  (3  E  dpv(C4)=E  A  E#  X  A  Isa(E  JO) 


33.4  EntlUes 

For  entity  objects,  we  introduce  a  new  sort,  D,  which  is  treated  as  a  subsort  of  T,C, 
and  M,  ir.  every  element  of  D  is  an  element  of  one  exactly  of  T,C,  and  M. 

33J6.1  BaUMn  Entity  Objects 

There  are  two  special  constants,  Dc  and  D^,  of  sorts  DO  C  and  Dfl  M,  respectively, 
corresponding  to  the  class  of  all  entity  tokens  ('ENTlTY_TOKEN'’  in  RML)  and  the  metaclass 
of  all  entity  classes  ('ENTITY_CLASS*  in  RML).  For  C  of  sort  DO  C,  Du  must  contain  Dc 

In(DcJ>M,t) 


and  Dc  is  the  *top'  of  the  ISA  hierarchy  of  the  entity  classes  in  Du: 
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VC  (ln(C  =>  Isa(C  J>c)l 


J  Property  Categories  for  Entitles 

For  each  property  category,  we  have  in  L  a  unary  predicate  of  sort  <I>,  which 
declares  an  sttribute  to  be  the  designated  property  category.  Throughout  this  section,  C  is  of 
sort  D,  i  is  of  sort  1,  and  the  sort  of  D  is  indicated  in  the  text. 

An  invariant  (i.e.  a  property  in  the  Invariant  property  category)  attaches  an  assertion 
that  is  true  throughout  the  time  an  object  is  in  the  class. 

{dpv(C4)=D  A  D#1  A  Invariant(i)}  =>  {(In(x,C,t)  =>  fpv(x4,t)#X) 


This  can  be  read  as  follows: 

(a)  Let  C  have  a  property  i  with  property  value  D  (not  null),  and 
^)  Let  i  be  an  invariant  property. 

(c)  Then  every  instance  x  of  C  is  such  that  its  property  value  is  non-null. 


[1]  All  of  the  property  category  definitions  below  can  be  read  similarly,  with  the  appropriate 
property  category  mentioned  on  line  (b)  and  the  appropriate  implication  mentioned  on  line 
(c). 


An  initial  condition,  ijc.  a  property  in  the  Inlteond  category,  attaches  an  assertion  that 
is  true  at  the  time  an  object  becomes  an  instance  of  the  entity  class.  We  define  a  predicate  to 
state  that  an  object  x  is  inserted  into  a  class  C  at  time  t;  x  must  have  been  not  an  instance  of 
C  for  some  time  interval  just  before  t  and  then  be  an  instance  of  C  at  t. 

Inserted(x,C,t)  =*  {  3  s  (s<  t)  A  Vs’  (ss;s’<t  ^  "In(x,C3’))  ^  In(x,C,t)  ) 


Now,  an  initial  condition  is  defined  as  follows: 

{dpv(C4)=D  A  D#  J.  A  Initcond(i)}  ^  (Inserted(x,C,t)  =>  fpv(x4,t)#X) 


This  says  that  an  initial  condition  for  a  class  is  true  for  an  object  at  the  time  the  object  is 
inserted  into  the  class.  We  define  a  predicate  to  state  that  an  object  is  removed  from  a  class 
at  a  time  s;  x  is  in  C  at  s,  but  immediately  thereafter  is  not  an  instance: 

Removed(x,C4)  ■  (  In(x,C4)  A  3 1  (s<  t)  A  Vs’  (s<s’st  =>  'In(x,C,t)  ] 


Note  that  it  is  possible  to  have  Inserted(x,C4)ARemoved(x,C4)  since  both  assert  that  x  is  an 
instance  at  s.  Now,  we  can  easily  define  a  property  category  for  'final  condition',  an  object 


[1]  Note  that  fpv(xj,t)#  X  u  all  that  needs  to  be  stated  to  say  fpv(x4,t)  is  a  true  assertion, 
since  by  the  property  induction  principle  fpv(x4,t)  must  therefore  be  an  instance  of  D. 
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that  is  true  at  the  time  an  object  is  removed  from  the  class. 

{dpv(C4)=D  A  D#X  A  Fmalcond(i)}  =>  {Removed(x,C,t)  =>  fpv(x4,t)#±} 


A  part  property  relates  an  entity  object  to  the  subject  of  the  property,  i.e.  the  sort  of 
the  property  value  is  D.  A  necessary  part  is  one  that  must  never  be  null;  we  define  the 
necpart  property  category  for  this: 

{dpv(C4)=D  A  J.  A  Necpart(i)}  =>  {In(x,C,t)  =>  fpv(x4,t)^  X  } 


Note  the  similarities  between  all  of  the  above-defined  property  categories.  For  example, 
necpart  and  Invariant  are  very  ^ilar  in  form,  the  main  difference  being  in  the  sort  of  the 
property  value  (D  for  necpart  and  A  for  Invariant).  The  axioms  for  these  two  property 
categories  simply  add  a  little  to  what  must  already  be  true  according  to  the  property 
induction  constraint.  From  property  induction  we  know  that  either  fpv(x4,t)  is  in  C  or  else  it 
is  X  ;  the  necpart  and  Invariant  property  categories  say  the  latter  is  not  the  case  and  thus  the 
former  must  be. 

We  now  define  property  categories  that  associate  activities  with  the  entity  subject.  (In 
the  following,  let  D  be  of  sort  E,  whose  elements  are  activities,  as  defined  in  the  next  section.) 

A  producer  property  attaches  an  activity  that  contributes  to  the  creation  of  an 
instance  of  the  class.  A  producer  may  insert  one  instance  or  several;  the  effects  of  two  or 
more  producers  may  be  needed  to  create  an  instance.  Additional  properties,  namely 
constraints,  are  used  to  say  which  is  the  case.  The  definition  of  producer  says  that  the 
activity  must  have  occurred  before  x  is  considered  an  instance  of  C: 

{dpv(C4)=D  A  D#  X  ^  Producer(i))  => 

{Inserted(x,C,t)  ^  B  s  s^  t  A  Removed(fpv(x44)  J>,s)} 


33  J  Activities 

For  activity  objects,  we  introduce  a  new  sort,  E  (E  for  Event,  since  A  is  being 
reserved  for  assertions),  which  is  treated  as  a  subsort  of  T,C,  and  M,  i£.  every  element  of  E  is 
an  element  of  one  of  T,C,  and  M. 

3J.7.1  Bnllt-ln  Activity  Objects 

There  are  two  special  constants,  Ec  and  Em,  of  sorts  EH  C  and  EH  M,  respectively, 
corresponding  to  the  class  of  all  entity  tokens  (''EN’nTY_TOKEN*  in  RML)  and  the  metaclass 
of  all  entity  classes  ('ENTrrY_CLASS''  in  RML).  For  C  of  sort  EH  C,  Em  must  contain  Ec 

In(Ec»EM>t) 
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and  Ec  is  the  'top*  of  the  ISA  hierarchy  of  the  entity  classes  in  Ey; 


VC  [In(C^ii.t)  =>  Isa(CJEc)l 


3J.7  J  Occorrcacc  of  Activtdcs 

We  introduce  two  functions,  start  and  end,  of  sort  <E  ;S>,  corresponding  to  the 
start  and  end  time  points  of  an  activity.  Activities  progress  in  time;  for  activity  x: 

8tart(x)  &  end(x) 


An  activity  is  an  instance  of  a  class  between  the  start  and  end  times: 

In(x,C,s)  <P>  start(x)  s  s  s  end(x) 

We  say  x  is  ac/ive  between  its  start  and  end  time  points.  It  will  be  convenient  sometimes  to 
speak  of  the  occurrence  of  an  activity: 

Occur(x4,t)  *■  [start(x)=s  A  stop(x)=t] 


3.3.7  J  Property  Categories  for  Activity 

In  the  following,  let  C  be  an  activity  class,  and  let  D  be  of  sort  CUM,  subsort  A, 
indicating  that  these  property  categories  associate  an  assertion  as  property  value. 

A  precondition  property  is  true  at  the  start  time,  while  a  postcondition  property  is  true 
at  the  end  time: 

{dpv(C4)=D  A  D#X  ^  Prccond(i))  ^  {In(x,C,t)  =>  fpv(x4,8tart(x))^  J.) 

{dpv(C4)=D  A  D#X  ^  Postcond(i))  ^  {In(x,C,t)  =>  fpv(x,i,end(x))#  J. } 


{dpv(C4)=D  A  D#  J.  A  Actcond(i)} 

^  {Inserted(y  J),t)  3  x  Inserted(x,C,t)  A  fpv(x4,t)=y) 

{dpv(C4)=D  A  D#  J.  A  Stopcond(i)} 

=>  {Inaerted(y  J),t)  =>  3  x  Removed(x,C,t)  A  fpv(x4,t)=y) 
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Entity  objects  can  be  related  to  an  activity  through  Input,  output,  and  control 
properties.  The  first  two  are  defined  as  follows: 

{dpv(C4)=D  A  ^  Input(i)) 

=>  {Occur(x,s,t)  =>  [  3  s’  s^s’st  A  Removed(fpv(xa4’)X>,5’)  ]} 

{dpv(C4)=D  A  D^X  Output(i)) 

=>  {Occur(x,s,t)  =>  (  3  s’  ss  s’ss  t  A  Inserted(fpv(x4,s’)X),s’)  ]} 


An  input  is  affected  by  the  activity  by  being  removed  from  its  property  value  class.  An  output 
is  affected  by  becoming  an  instance  of  its  property  value  class. 

A  control  is  an  entity  related  to  the  activity  with  the  proviso  that  the  activity  does  not 
(intentionally)  remove  the  entity  from  its  property  value  class  (although  the  entity  may 
indeed  be  removed  during  the  time  interval  when  the  activity  occurred).  To  express  this 
sense  of  control,  we  would  need  to  be  able  to  express  that  an  activity  intends  to  change  some 
property;  we  will  not  deal  with  this  problem  here. 

3  J  J  Aasertlons 

We  introduce  a  new  subsort.  A,  for  assertions,  and  as  for  entities  and  activities,  we 
add  the  special  built-in  objects. 

Two  property  categories  for  assertions  are  parts,  which  are  non-X  assertions,  and 
arguments,  which  are  non-X  objects  of  any  object  category.  Parts  are  true  if  the  subject 
assertion  is  true.  The  combination  of  arguments  of  an  assertion  must  be  unique.  The 
arguments  of  an  assertion  must  be  non-null  and  each  unique  combination  of  arguments  yields 
a  unique  assertion  token. 

{In(x,C,t)  A  In(y,C,t)  A  x=^y)  =>  {"  Vi  (fpv(x4,t)=fpv(y4,t)D 


For  every  assertion  class  C  with  n  properties  al,...,an  in  the  argument  category,  L 
contains  a  corre^onding  predicate  (say)  A  of  n+l  arguments,  the  last  place  of  sort  time,  such 
that  the  predicate  holds  for  the  given  arguments  if  and  only  if  there  is  a  corresponding  token 
in  the  class. 


In(x,C,s)  A(fpv(x,al4),...,fpv(x,an,s),s) 
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3.4  TrauUdoB  from  RML  Co  L 


The  function  t  defines  the  translation  from  RML  to  L. 

3.4.1  BoUC-Ib  Objects 

The  built-in  RML  objects,  such  as  ENTITY,  EN’nTY_CLASS,  and  so  on,  translate  to 
their  counterparts  in  L: 

t(ENTITY_TOKEN)  =  Dc 
T(EN'nTY_CLASS)  = 

T(AC'nVITY_TOKEN)  =  Ec 
t(ACTIVITY_CLASS)  =  Em 
t(ASSERTION_TOKEN)  =  Ac 
t(ASSERTION_CLASS)  =  \m 


3.4  J  RML  AasertloB  ExprcsaloBi 

The  expressions  in  the  RML  assertion  expression  language  translate  into  the  obvious 
formulae  of  L.  a  and  ^  are  expressions  of  RML. 

T(a  cmd  P)  =  T(a)  A  T(W 
T(a  or  ^)  =  T(a)  V  t(P) 
t(/io/  a)  =  ■  T(a) 

T(a  implies  p)  =  t(o)  ^  tO) 
r{Exists  y  a)  =  3  y  T(a) 
tiForall  y  o)  =  Vy  T(a) 

T(a=^)  =  (T(a)=T(^)) 

T(a)  =  a,  if  a  is  a  constant  or  variable  symbol. 


3.4.3  Predicates  and  FonedoBS 


t(IN(o,P.7))  =  In(t(a),T(p),T(T)) 

TaSA(B.W)  = 

t(P  (aj,...))  =  P  (T(ai),...)  for  other  predicates  P , 
including  comparators  of  time. 

T(RANGE(a4))  =  dpv(T(a)4)) 

t(PVAL(o4,P))  =  fpv(T(a)4.TO)) 


3.4^  Abbrevlatloiis 

In  RML,  we  are  allowed  to  leave  off  the  time  argument  to  the  PVAL  function,  using 
*•'  notation,  and  we  can  omit  the  time  argument  for  the  IN  predicate.  When  the  time 
argument  is  missing,  the  translation  inserts  the  default  time  now .  Thus, 

T(IN(a,p))  =  T(IN(a,^4tow)) 

T(a•^)  =  T(PVAL(a,P4uw) 

In  a  given  expression,  all  missing  time  arguments  are  replaced  with  the  same  symbol  now. 
Then,  any  expression  containing  now  is  translated  by  replacing  now  with  a  unique  variable  of 
sort  time  and  making  that  variable  universally  quantified  over  the  whole  formula. 

The  special  symbol  self  works  like  now  ^  except  self  acts  as  the  subject  of  the 
property  category  definition.  In  an  expression,  all  occurrences  of  self  are  replaced  by  a 
variable  of  the  same  category  sort  as  the  subject,  one  that  is  unique  over  the  expresion  and  is 
universally  quantified  over  the  whole  expression. 

Any  attribute  symbol  appearing  alone,  e.g.  in  a  binding  expression,  is  assumed  prefixed 
by  self  ,  so  that  a  property 

a  :  D(xd>) 

in  the  definition  of  class  C  expresses  (for  the  typical  instance,  self  )  the  equality: 

self  •  a  •  X  =  b 


3.43  Class  Definition 

Suppose  we  encounter  a  class  definition  of  the  general  form  [1] 


[1]  As  in  Appendix  B: 

[a]  signifies  that  a  is  optional 

(a)  signifies  zero  or  more  occurrences  of  a 

{a}+  signifies  one  or  more  occurrences  of  a 
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C  Im  <cla«iflcr>  isa  {  <supercla88>  )+ 


{  <pcat>  ) 

{  <  attr>  :  <  pval>  [  <  bindiDg8>  ]  ) 


We  must  add  the  following  symbols  to  L: 

Make  C  a  constant  symbol  of  the  same  category  sort  as  <classifier> 
and  of  the  appropriate  classification  level 
(ir.,  if  sort  <  classifier>  is  C  then  sort  of  C  is  T, 
if  sort  <  classifier>  is  M  then  sort  of  C  is  C). 

(Entities  are  added,  but  not  now,  for  <pval>  and  <  superclass>  ;  they  are 
added  when  they  are  declared  elsewhere.) 


We  must  add  the  following  axioms: 

In(C,<  clas8ifier>  ,t) 

Isa(C,<  superclas8>  )  for  each  superclass 

dpv(C,<  attr>  )  =  <  pval>  for  each  property 

[  A  fpv(je//  c,<  attr>  ,t)^  J_  =>  t(<  bindings>  )  ] 

If  peat  is  the  predicate  of  L  that  corresponds  to  the  property  category 
<pcat>  then  add  the  axiom  pcat(i) 


A  binding  expression  is  of  the  form 

(  {<  attr-i>  :  <  val-i>  }  ) 


which  translates  to 


{A  T(In(selfc*  <  attr>  •  <  attr-i>  ,<  val-i>  ,t)  ) 

where  the  variable  t  is  the  same  one  as  in  the  translation  above  for  dpv(C,<  attr>  ).  That  is, 
if  a  binding  expression  appears  for  a  property,  then  an  axiom  is  added  to  the  effect  that 
whenever  the  property  value  is  non-null,  the  bindings  (equality  constraints)  hold. 


3Aji  Example  Translatloa 


Here  is  an  example  of  the  translation.  Consider  the  following  entity  class  extracted 
from  Appendix  C. 
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SUBMTTTED.PAPER  in  PAPER_CLASS  isa  CONF_PAPER  with 
producer 

submit:  SUBMn'_PAPER(q;>:  self,  to:  conf) 

Inrarlant 

s:  SUBMnTED(paper:  self,  confxonf) 
part  date-submitted:  DATE 


We  must  add  a  symbol,  designating  an  entity  class,  i.e.  a  symbol  of  sort  DH  C.  [1] 

We  add  the  following  axioms: 

For  the  first  line: 

InCSUBMITTED  PAPER,  PAPER_CLASS,t) 

MSUBMITTEdIpAPER,  PAPER) 

For  properties  (with  bindings): 

dpv(SUBMnTED_PAPERAubmit)  =  SUBMIT^PAPER 
A  {(fpv(jel/  ,submit,t)#X  ^ 

(fpv(fpv(je//  ,submit,t),sp,t)=rr// 

A  fpv(fpv(re//  ,nibmit,t),to,t)=8elf))} 

dpv(SUBMnTED_PAPER,s)  =  SUBMITTED 
A  {(fpv(re//  ,s,t)#X  => 

(fpv(fpv(je//  ,s,t),paper,t)=ie// 

A  fpv(fpv(rr//  4,t),confl,t)=confl))} 

dpv(SUBMnTED_PAPER, date-submitted)  =  DATE 

Producer(submit) 

Invariant(s) 

Part(date-submitted) 


[2] 


[1]  For  simplicity,  we  will  just  use  the  RML  identifiers  as  the  symbols  of  L. 

[2]  Note  that,  although  *conf*  is  allowed  in  RML  to  represent  different  attributes,  we  must 
make  them  distinct  elements  of  the  logic. 
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9  J  CouliteBcj 


Given  the  equivalence  of  an  RML  ^>ecification  with  a  FOL  axiom  set,  we  can  now 
define  a  general  notion  of  consistency  of  an  RML  specification.  Namely,  an  RML  model  is 
said  to  be  consistent  if  its  FOL  translation  is  logically  consistent. 

Furthermore,  since  RML  has  assertion  objects,  anything  that  can  be  expressed  in  the 
FOL  can  be  stated  in  RML. 
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CHAPTER  4 

MORE  FEATURES  OF  RML 


4.1  Uiliig  MelacUaet 


4.1.1  MeUpropertie* 


We  have  seen  that  any  object  can  have  factual  properties  while  only  classes  and 
metaclasses  can  have  definitional  properties.  We  now  introduce  a  third  kind  of  property, 
metaproperties t  which  can  be  had  only  by  metaclasses.  A  metaproperty  expresses  information 
about  all  of  the  classes  in  the  metaclass  to  which  it  is  attached.  By  analogy  to  property 
induction  between  definitional  and  factual  properties,  metaproperties  are  said  to  induce 
definitional  properties. 

A  metaproperty  is  of  the  form 

[Mji^lassof  D] 

where  D  is  a  class.  The  property  induction  works  as  shown  below: 


i 


M  — 


— }  class-of  D 


I 


1 


i 


D’ 


I 


X 


Id 


4 


For  any  instance  C  of  M,  C  has  the  definitional  property  i  which  induces  factual  properties  on 
the  instances  of  C.  For  D’  to  be  properly  induced,  D’  must  be  a  subclass  of  D.  The 
metaproperty  lM4/:iass-o/  D],  written  in  RML  as 

meCa  i:  class  of  D, 
says  that  instances  of  M  have  the  i  definitional  property. 

I 
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4.1  J  tlMm-at  CoQiCnictor 


One  can  define,  inline,  metaclasses  of  the  form 

class-of  C 

for  any  already  defined  class  C.  This  can  occur,  for  example,  in  expressions  such  as 

M  =  class-cf  C 

or 

D  with  i:  class-cf  C 

Any  class  declared  to  be  an  instance  of  class-of  C  has  as  instances  only  instances  of  C.  For 
example, 

STUDENT  in  class-of  PERSON 

implies  that  every  instance  of  STUDENT  is  an  instance  of  PERSON.  More  concisely, 

ISA(STUDENT,PERSON). 

We  define  the  special  metametaclass  CLASSOF-CLASS  so  that  its  instances  behave 
accordingly. 

metametaclass  CLASSOF-CLASS 
part  base:  CLASS 
Invarlaat  a;  ISA{SELF  ,base) 


Now  the  declaration 

STUDENT  in  CL  ASSOF-CLASS(basc  PERSON) 
which  can  also  be  written  in  inline  notation 

STUDENT  in  class-of  PERSON 


defines 

and 


class-of  PERSON  with  base=PERSON 
STUDENT  with  a =ISA(STUDENT PERSON) 


The  class-of  constructor  can  be  used  for  any  object  category.  Also,  class-of  C  can  be 
declared  for  any  class  C,  but  the  converse  is  not  true:  it  is  not  automatically  the  case  that  for 
every  class  C  there  is  a  class-of  C  metaclass  -  only  when  specified.  Also, 

class-of  C  isa  class-of  D  if  C  isa  D 

which  means  that  the  isa-hierarchy  of  metaclasses  formed  using  the  class  -of  constructor  are 
ordered  relative  to  the  base  classes. 


4.1  J  Special  Entity  ClasMS 

It  is  useful  to  be  able  to  define  a  class  that  is  a  union  of  two  or  more  classes,  so  that 
an  object  is  in  the  'union  class'  if  it  is  in  one  or  more  of  the  given  classes.  We  wish  to  define 
in  RML  a  metaclass,  such  that  instances  have  the  property  that  their  instance  sets  are  formed 
by  the  union  of  the  involved  classes.  We  first  take  the  case  of  two  classes: 

UNION^CLASS 
part  classl:  CLASS 
part  class2:  CLASS 

Invariant  al:  ISA(classiPELF)  and  ISA(class2P£LF  ) 

Invariant  a2:  IN(xPELF)  implies  IN(x,classl)  or  IN(x,class2) 


Now,  the  expression 
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UNION2-CLASS(clas8l5TUDENT,cIas82£MPLOYEE) 
or  the  inline  expression  (if  provided  in  RML) 

unioH-of  STUDENT*  EMPLOYEE 

which  binds  specific  objects  to  the  two  properties*  is  an  instantiation  of  the  metaclass,  and  is 
the  class  that  is  the  union  of  students  and  employees*  having  by  factual  properties  the  two 
classes  that  are  joined  and  two  properties  making  assertions*  the  first  saying  that  the  two 
classes  must  be  subclasses  of  the  union  class,  and  the  second  insuring  that  the  union  class  is  a 
least  upper  bounds 

If  we  wanted  the  union  of  several  classes*  we  could  create  a  metaclass  containing  all  of 
the  involved  classes  [1]  and  then  define  the  union  over  its  instances. 

UNION-CLASS 

put  m:  METACLASS 
Invulant  al:  forall  C  inm 

ISA(C^ELF) 
iBwartMat  a2:  IS (x^ELF)  implies 

exists  C  inm  such  that  IN(x,C) 


The  first  invariant  places  a  union  class  above  all  of  the  involved  classes  and  the  second  one 
makes  the  union  class  the  least  upper  bound. 

Similarly*  we  can  define  an  intersection  of  classes. 

INTERSECT-CLASS 
part  m:  METACLASS 
Invariant  ul:  for  ail  C  inm 

ISA(5£LF  *C) 

Invariant  a2:  if  forall  C  inm  IN(x,C) 
then  IS(%^ELF) 


al  places  the  intersection  class  below  all  of  the  involved  classes  on  the  ISA  hierarchy,  and  a2 
makes  sure  that  the  intersect  class  is  their  greatest  lower  bound. 

Another  way  to  model  such  classes  as  imions  and  intersections,  in  the  case  that 
property  categories  were  considered  classes  of  properties*  would  be  as  follows: 


[1]  Most  often  the  metaclass  would  be  defined  as  a  finite  enumeration  of  classes  using  the 
notation  {I  Cl*  C2*  C3  1). 


UNION-CLASS 

operand 

ilCLASS 

i2CLASS 

i3.CLASS 

tavarlant 

%l:forall  p  In  operand 

ISA(5ELF  •  dp,  SELF) 
a2:  IN(x^£L/’)  implies 
exists  p  in  operand 
such  that  m(x^ELF  •  dp) 


We  have  not  added  properties  such  as  commutativity  and  associativity  for  these 
constructed  classes;  in  fact,  for  the  case  of  UNION2-CLASS,  there  does  not  seem  to  be  a  way 
to  do  this  in  the  framework  as  it  stands,  since,  for  example, 

UNION2-CLASS(cla88lC,  class2£>) 

can  not  be  the  same  object  as 

UNION-CLASS2(cIasslJ>,  clas82<:). 

(However,  if  the  framework  worked  according  to  multiple  property  induction,  as  mentioned 
earlier,  then  classl  and  class2  could  be  induced  by  the  same  definitional  property  and  the 
approach  of  the  last  footnote  used,  and  commutative  and  other  properties  would  indeed 
apply.) 

Other  useful  entity  metaclasses  can  be  formed  in  the  same  style  as  above. 
Combinations  are  useful,  too,  such  as 

class-cf  taiion-of  C  J) 

with  expected  rules  such  as 

class-of  union-of  (C  J>)  =»  tmion-of  (class-of  C,  class-cf  D) 

4.1^  AiKrtloB  MeUclanes 

We  can  define  special  assertion  metaclasses  so  that  their  instances  have  the  properties 
of  logical  connectives.  Some  examples  are: 

OR2-CLASS 

part  classl:  CLASS 
part  class2:  CLASS 

Invariant  al:  ISA(classl,5£LF)  and  ISA(class2,S£L£) 

Invariant  a2:  IN(x,5£L£)  implies  IN(x,cla88l)  or  IN(x,cla8s2) 
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AND2-CLASS 

part  classl:  CLASS 
part  class2:  CLASS 

Invariant  al:  ISA{SELF  ,classl)  and  ISA(5£LF  ,class2) 
Invariant  a2:  if  IN(z,classl)  and  IN(x,class2)  then  Ui{xJSELF  ) 


Note  that  these  are  the  same  as  for  union  and  entity  classes,  respectively. 

For  describing  universal  quantification,  we  can  define 

UNIVERSAL-CLASS 
meta  i:  class-of  C 
Invariant  al:  forall  x  in  SELF  •  oi 
exists  y  in  SELF 
such  that  yai=x 


The  metaproperty  [1]  introduces  the  'quantified  variable'  and  the  invariant  says  that  there  is  a 
properly  teund  assertion  object  in  SELF  for  every  instance  of  the  'range'  of  the  variable. 

Similarly,  a  class  of  existentially  quantified  assertions  would  be  an  instance  of  the  metaclass: 

EXISTS-CLASS 
meta  i:  class-of  C 
Invariant  al:  exists  x  in  SELF  •  •  i 

such  that  exists  y  and  y*  i=x 


4.U  Activity  Metaclaaws 

For  activities,  we  can  define  metaclasses  analogous  to  those  for  entity  and  assertion 
and  defined  precisely  in  the  same  way.  For  example:  DO-ONE-OF-CLASS  (which  is 
analogous  to  UNION-CLASS  and  OR-CLASS)  whose  instances  are  said  to  occur  when  one  or 
more  of  the  involved  classes  occurs,  and  DO-ALL-CLASS  (which  is  analogous  to 
INTERSECT-CLASS  and  AND-CLASS)  whose  instances  are  said  to  occur  when  all  of  the 
involved  classes  occur. 

Analogous  to  UNIVERSAL-CLASS,  we  can  define: 


[1]  Under  the  assumption  of  single  property  induction,  i  is  the  name  of  a  definitional  property 
of  every  instance  of  UNIVERSAL-CLASS.  A  constraint  such  as  ARGUMENT(i)  would 
express  the  fact  that  i  is  in  the  argument  property  category. 
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DOFOREACH-CLASS 
aKta  i:  class-of  A 
Invariant  %\:forall  i  in  SELF  •  ai 
there  exists  y  in  SELF  with 
yai=x 


A  class  in  this  metaclass  contains  a  token  activity  for  every  element  of  the  range  of  i,  and  the 
class  is  said  to  occur  precisely  when  all  of  the  instances  have  occurred.  Note,  however,  that 
each  action  y  occurs  in  some  un^ecified  time  interval  but  there  are  no  expressed  constraints 
on  the  relationships  between  these  intervals.  If  one  wanted  to  ^>ecify  that  they  all  happened 
concurrently,  one  could  add 

constraint 

concurrent:  for  all  yl,y2  in  SELF 

yla  St  art  =72*  start  and  ylnend=72*end 


In  section  4J,  we  will  introduce  time  intervals,  so  that  each  activity  will  have  a  time  interval 
instead  of  startyend  times;  this  will  make  the  expression  of  such  constraints  more  convenient. 
The  concurrency  constraint  above  would  be 

concurrent:  for  all  yl,y2  in  SELF 

start(yl)=start(y2)  and  end(yl)=end(y2) 


and  a  constraint  that  no  two  activities  should  occur  concurrently  would  be 

exclusive:  for  all  yl,y2  in  SELF 
not  OVERLAPi>l,y2) 


where  OVERLAP  is  defined  appropriately  (see  section  43.). 

It  should  be  mentioned  that  constraints  such  as  'concurrent*  and  'exclusive'  are  often 
not  required  explicitly  but  rather  are  implied  by  other  constraints.  For  example,  an  activity 
consisting  of  two  parts,  one  of  which  receives  its  input  from  the  other,  may  already  have 
stated  implicitly  the  required  constraint,  since  pi  and  p2  must  exist  at  the  same  times  if  al  is 
to  hold. 

A 

part 

pi:  Al 
p2:  A2 
constraint 

al:  pl*01=p2«Il 
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Conceptual  Modellnf  of  Time 

As  another  example  of  modeling  using  RML,  we  take  the  example  of  time  concepts. 
Representation  of  time  concepts  has  been  recognized  as  very  important  in  modeling  of 
application  domains  and  a  lot  of  research  has  gone  into  representing  time  in  databases 
[BalourSl]  and  AI  [AllenSl].  The  difficulty  is  due  to  the  fact  that  we  are  not  dealing  with  a 
particular  notion  of  "state*  as  in  programming  languages  but  rather  we  need  to  deal  with 
worldly  notions  of  time  passing,  activities  happening  within  certain  time  intervals,  certain 
activities  happening  while  others  are  happening  (or  not  happening),  and  so  on. 

First,  note  that  the  possible  expressions  of  time  are  very  rich,  and  so  it  is  hard  to 
discriminate  between  ambiguous  and  vague  things.  For  example,  "happens  on  Thursdays" 
could  mean:  completely  on  Thursday;  starting  on  a  Thursday;  happens  every  Thursday;  when 
it  happens  it  happens  on  Thursday;  etc.  We  need  the  power  to  make  these  distinctions,  and 
furthermore,  we  need  to  be  able  to  organize  such  information  to  make  it  easy  to  understand. 

Second,  note  that  times  are  closely  linked  to  activities.  Based  on  an  observation  by 
[BubenkoSO],  we  view  time  intervals  as  activities,  since  they  have  start  and  end  and  their 
passing  can  be  modeled  after  the  occurring  of  an  activity.  We  will  actually  let  RML  time 
objects  be  activities. 

A  scheme  for  modeling  time  in  RML  is  given  in  which: 

a.  The  modeler  defines  an  activity  class  for  each  time  unit  (e.g.  sec,  min,  hr,  ...),  and 
instances  are  time  intervals.  A  time  point  is  an  interval  of  the  smallest  size  of  interest 
(as  in  [AllenSl]). 

b.  An  interval  is  not  constrained,  as  in  most  time  modeling  schemes,  to  be  a 
clock/calendar  interval  (e.g.  an  "hour"  can  start  at  any  point,  not  only  at  12o’clock, 
lo’clock,  etc.).  One  or  more  clock/calendar  systems  can  be  imposed  by  specializing  the 
basic  time  unit  classes. 

c.  Time  intervals  are  treated  as  activities  (as  for  Bubenko’s  "time  events"),  which  occur 
between  their  start  and  end  times. 

d.  One  can  specify  "vague*  times  by  specifying  that  the  start/end  attributes  are  larger 
rather  than  smaller  intervals. 

e.  Through  RML  assertions,  a  set  of  useful  predicates  on  time  intervals  are  offered  as  in 
[AllenSl]:  DURING,  BEFORE,  EQUAL,  (asymmetric)  OVERLAPS,  MEETS.  In 
addition,  each  time  interval  has  a  "next*  property  that  gives  its  temporal  successor  of 
the  same  type  (e^.  the  minute  that  begins  where  another  ends),  which  amount  to  a 
bunch  of  built-in  MEETS  assertions. 

Using  this  scheme,  a  great  variety  of  useful  time  concepts  can  be  modeled,  e.g.. 
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-  •  certain  activity  happens  on  Thursdays  only. 

-  an  activity  lasts  for  the  length  of  one  hour. 

•  at  noon. 

•  one  activity  happens  while  another  happens. 

•  etc. 


The  reader  can  imagine  interesting  and  complex  examples  of  time  expressions  that  mix  times, 
assertions,  the  occurrence  of  activities,  and  so  on.  [1] 

4J.1  Intervals 

We  define  TIME-INTERVAL  as  the  class  of  all  time  intervals.  We  define  a  subclass 
of  TIME-INTERVAL  for  each  useful  class  of  time  intervals.  Each  time  interval  has  a 
'duration'  property,  so  one  way  to  come  up  with  interesting  subclasses  of  TIME-INTERVAL 
is  to  place  constraints  on  the  permissible  values  of  the  duration  for  intervals  in  the  subclass. 
In  particular,  we  are  interested  in  subclasses  all  of  whose  instances  are  of  some  fixed  length 
corresponding  to  a  common  time  'unit'  such  as  second,  minute,  hour,  and  so  on. 


SEC-INT  MIN-INT  HR-INT  DAY-INT  WEEK-INT  MO-INT  YR-INT 


It  is  important  to  understand  that  the  instances  of  these  classes  are  intervals,  not  'instants'  in 
the  intervals.  Furthermore,  the  notion  of  time  'point'  is  used  to  mean  the  'smallest'  unit  of 
interest  (e.g.  second  here).  One  should  also  note  that  intervals  are  more  general  (and 
numerous)  than  the  named  intervals  on  a  clock  or  calendar.  For  example,  HOUR-INT 
contains  not  only  the  24  special  hour-long  intervals  demarcated  by  a  standard  clock,  but  all 
hour-long  intervals  (one  beginning  at  every  time  'point').  We  will  treat  the  standard 
clock/calendar  intervals  as  specializations  of  the  general  fixed-length  intervals,  e.g. 

NOON-HOUR  isa  HOUR-INT 
is  the  class  of  hours  starting  at  the  first  second  of  noon. 

There  will  be  other  interesting  classes  of  time  interval  objects,  for  example  the  class  of 
all  intervals  that  begin  during  a  certain  interval.  In  order  to  define  these  precisely,  we  first 
introduce  some  useful  assertions  that  deal  with  time  objects. 


[1]  The  reader  will  notice  that  there  does  not  seem  to  be  a  reason  why  ANY  units  of 
measurement  cannot  be  modeled  in  a  way  analogous  to  how  time  is  modeled. 


-49- 


422  BaMc  Aswrtloas  about  Time 


Following  [AllenSl]  we  offer  five  primitive  binary  relations  on  time  intervals.  We  use 
RML  assertions  to  integrate  these  into  the  framework. 

DURING(tl,t2)~time  interval  tl  is  fully  contained  within  t2,  although  they  may  coincide  on 
their  endpoints. 

BEFORE(tl,t2)~time  interval  tl  is  before  interval  t2,  and  they  do  not  overlap  in  any  way. 
OVERLAP(tl,t2)>-interval  tl  starts  before  t2,  and  they  overlap. 

MEETS(tl,t2)~interval  tl  is  before  interval  t2,  but  there  is  no  interval  between  them,  i.e.  tl 
ends  where  t2  starts. 

EQUALS(tl,t2)-tl  and  t2  are  the  same  interval. 

Among  the  axioms  for  these  predicates  are,  informally: 

•  BEFORE  is  transitive. 

•  Two  intervals  that  overlap  have  a  common  subinterval. 

•  If  two  intervals  meet,  then  there  is  no  interval  between  them. 

-  If  two  intervals  meet  or  one  is  before  the  other,  they  have  no  common  subinterval 
More  axioms  are  given  in  [AllenSl]. 

All  of  these  axioms  can  be  specified  in  RML  by  attaching  assertions  as  constraints  to 
the  class  TIME-INTERVAL  and  letting  tl  and  t2  play  the  roles  of  self  1  and  self  2  (i.e.  any 
two  instances  of  the  class). 

422  Special  Properties  of  Time  Objects 

We  define  'start'  and  'end'  as  properties  whose  values  are  time  points,  here  seconds: 

TIME-INTERVAL  in  TIMEINTERVAL-CLASS  with 
part 

start:  SEC-INT 
end:  SEC-INT 


We  can  add  constraints  to  the  effect  that  a  start  point  begins  no  later,  and  the  end  point  no 
earlier,  than  any  other  subinterval  of  the  given  interval: 

DURING(s,t)  implies 

{not  BEFORE(s,t*  start)  and  not  MEETS(s,t  •  start) 
and  not  BEFORE(tOend4)  and  not  MEETS(t*end,s)} 


Each  interval  class  in  the  ISA-hierarchy  shown  above  defines  fixed-length  intervals.  Fixed 
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length  intervals  have  a  property  'next*  that  has  as  value  the  next  interval  of  the  same  length. 
This  can  be  expressed  as  follows; 

metaclast  FIXEDINT-CLASS 

mela  next:  TIME-INTERVAL 
constraint  a:  SELF  *  *next=5£L/' 


FIXEDLENGTH-INT  in  FIXEDINT-CLASS 
constraint  b:  MEETS(ie//  ^elf  •  next) 


[1]  Thus,  when  applied  to  a  second,  'next*  produces  the  next  second,  when  applied  to  a 
minute,  it  produces  the  next  minute,  and  so  on. 

We  can  introduce  an  RML  abbreviation  for  one  or  more  applications  of  a  property 
selector.  We  will  let,  for  example, 

(t«rte«^) 

be  an  RML  abbreviation  for 

t  •  next  •  next 

4J.4  Special  Calendar/ Clock  Intervals 


^TIME-INTERVAL 

^  T 

MIN-INT  HR-INT 

/  t 

^'-<®Cr»MINUTE  ClOcXhOUR 

/  1 

AM-HOUR  PM-HOUR  WEEKDAY  WEEKENDDAY 

/  r  y"  /  y  ] 

HRl  HR2...  MONDAY  TUESDAY  SATDAY  SUNDAY 


This  diagram  shows  some  of  the  special  time  intervals  that  correspond  to  our  usual  notion  of 
calendar  or  clock. 

The  usual  notions  of  'calendar  date'  or  'clock  time'  can  be  modeled  as  aggregates. 
For  example. 


\ 


DAY-INT 


tAL.DAY 

t 


[1]  Here  we  have  treated  'points'  differently  than  [AllenSl]  in  that  Allen  asserts  that  points  do 
not  meet.  This  way  we  get  a  finite  number  of  time  points  but  lose  some  flexibility. 
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CAL-DATE  isa  DAY  with 
pttrt* 

month:  CAL-MONTH 
year:  CAL- YEAR 
constraints 

a:  DURING(month,year) 
b:  DURING(re//  ^onth) 

CLOCK-TIME  isa  MINUTE  with 
part  hour:  HOUR 
constraint  a:  DURING(jW/  4tOUR) 


42S  Time  Objects  as  Actlrltles 

For  another  example,  we  can  say  that  instances  of  a  certain  activity  class  can  happen 
only  on  Thursdays  as  follows: 

Activity-class  E 

constraint 

Exists  t  in  THURSDAY  such  that 

DURING(sc//  •  duration,  t) 


Suppose  we  want  to  say  that  the  activity  of  giving  a  lecture  fills  a  50  minute  time 
interval,  ending  on  the  hour.  It  is  convenient  to  have  (as  in  [AllenSl])  a  predicate 

SAME-END 

args 

tl:  TIME-INTERVAL 
t2:  TIME-INTERVAL 

defn 

a:  Exists  t  in  TIME-INTERVAL  such  that 
MEETS(tl,t)  and  MEETS(t2,t) 


and  then  to  define 

GIVE-LECTURE 

constraints 

bl:  duration  =3000  /‘seconds*/ 
b2:  Exists  t  in  HOUR 

such  that  SAME-END(5e//  ,t) 


which  says  that  a  lecture  time  is  of  length  3000  seconds  and  ends  precisely  when  some  hour 
ends. 
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CHAPTERS 

THE  SADT  •  RML  CONNECTION 


5.1  lAtrodoctloB 

An  important  issue  for  requirements  modeling  is  how  to  begin  constructing  a  model 
from  the  beginning.  RML  has  conceptual  tools  for  organizing  a  model,  and  they  can  serve  as 
dimensions  for  guiding  the  modeling  task:  in  particular,  the  ISA  dimension  can  guide 
modeling  from  most  general  to  most  specialized  concepts  [Borgida83].  However,  the  problem 
still  remains  how  one  should  conduct  the  initial  steps  of  modeling. 

In  this  chapter,  we  propose  that  a  *box-and-arrow'  technique  be  used  to  introduce  the 
relevant  terms  and  organize  them.  Then  the  semantics  of  the  terms  can  be  added  using  a 
'semantic  modeling  language*.  We  have  chosen  to  work  with  SADT  as  the  box-and-arrow 
language,  [1]  because  it  has  a  precise  notation,  is  well-documented,  and  has  a  high  profile  in 
both  business  and  academia.  The  general  problem  can  be  motivated,  however,  by  other 
language  choices,  and  the  results  here  can  be  applied  by  devising  a  similar  relationship 
between  other  languages.  We  see,  for  example,  that  [Lundeberg82]  conducts  an  analysis  of 
the  IFIP  working  conference  example  with  a  scheme  not  unlike  SADT,  while  [BubenkoSl] 
approaches  the  same  task  with  a  language  more  on  the  level  of  RML.  No  one  has  approached 
the  problem  of  how  to  combine  these  two  levels,  although  there  is  obviously  concurrence  that 
each  level  is  useful  in  its  own  right. 

In  effect,  we  propose  that  requirements  modeling  be  divided  into  two  tasks: 

1.  Structural  modeling  (using  boxes  and  arrows)  ~  Decide  what  are  the  relevant 
concepts;  decide  on  what  to  call  them;  organize  into  a  'model'  by  connecting 
graphically. 

2.  Semantic  modeling  ~  create  a  generic  object  in  RML  for  each  concept  named  in  the 
SADT  model;  give  object  definitions  in  RML. 

This  chapter  will  show  that  the  derivation  of  an  RML  model  from  an  SADT  description  can 
be  relatively  straightforward;  this  is  not  accidental,  since  RML  was  designed  with  SADT  in 
mind. 


[1]  SADT  stands  for  The  Structured  Analysis  and  Design  Technique  and  is  a  trademark  of 
Softech,  Inc.,  of  Waltham,  Massachusetts.  SADT  refers  to  a  complete  methodology  for 
requirements  definition  [Ros877a],  including  a  graphical  documentation  language,  well-defined 
personnel  roles,  training  programs,  standards,  and  so  on.  However,  we  are  primarily 
interested  in  its  graphical  language  and  will  use  'SADT*  as  the  name  of  the  language.  All  of 
the  features  of  SADT  that  are  referred  to  in  this  thesis  are  described  in  [Ross77b]. 
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SADT  provides  a  language  of  boxes  and  arrows  for  describing  data  and  activity  aspects 
of  some  woiid/system.  The  boxes  and  arrows  are  labeled  using  an  "embedded*  language, 
usually  English  (or  some  other  natural  language).  Although  SADT  is  very  useful  for  initially 
modeling  the  world,  much  of  the  information  contained  in  an  SADT  description  is  captured  in 
the  embedded  natural  language;  RML  can  be  used  to  formalize  this  information. 

Furthermore,  it  is  proposed  that  creating  an  SADT  model  first  makes  RML  modeling 
significantly  easier,  that  SADT  provides  a  bridge  between  people’s  mental  models  and  an  RML 
semantic  model.  In  the  first  place,  creating  an  SADT  description  is  much  easier  than  directly 
encoding  knowledge  into  RML;  SADT  deals  with  a  smaller  number  of  modeling  principles  and 
does  not  force  the  modeler  to  consider  the  world  in  as  much  detail  as  RML  does.  The  SADT 
description  provides  a  kind  of  structured  lexicon^  which  guides  the  RML  modeler. 

A  key  feature  of  SADT  is  that  descriptions  are  constrained,  in  that  two  concepts  are 
related  if  and  only  if  they  are  connected  by  the  graph  structure.  However,  equally  important 
to  the  role  SADT  plays  in  requirements  definition  is  that  the  diagrams  are  otherwise  open  to 
interpretation.  This  allows  modelers  to  discuss  the  structure  and  content  of  what  is  being 
described  without  getting  ittvolved  in  how  to  represent  and  define  things  at  the  level  of  detail 
of  RML. 

The  entity  and  activity  objects  of  RML  correspond  to  data  and  activity  concepts  in 
SADT.  Both  languages  have  the  characteristic  that  the  two  kinds  of  objects  can  be  related  to 
each  other  symmetrically.  RML  adds  the  semantic  structures  of  the  basic  framework  (classes, 
property  categories,  ISA  hierarchies)  and  its  assertions  provide  the  expressive  power  to  say 
whatever  is  necessary  to  completely  specify  what  is  intended. 

One  thing  we  are  NOT  trying  to  do  here  is  to  provide  a  formal  definition  for  the 
SADT  language.  Rather,  we  show  that,  given  an  SADT  model,  deriving  an  RML  model  is 
straightforward.  We  look  at  the  grr.phical  components  of  an  SADT  model  (boxes,  arrow 
connections,  dividing  and  merging  arrows)  and  investigate  the  choices.  It  turns  out  that  the 
choices  can  be  made  fairly  straightforward  (but  obviously  not  algorithmic,  since  the  RML 
modeler  must  add  new  information).  Furthermore,  the  resulting  RML  model  contains  mostly 
simple  statements,  such  as  properties  and  simple  equalities. 

In  the  next  section,  we  give  a  concise  introduction  to  SADT,  which  is  taken  fairly 
directly  from  the  literature,  so  we  can  distinguish  its  'official'  meaning  from  additional 
meaning  that  we  read  into  a  specification  in  order  to  decide  how  to  formalize  it.  Then,  we 
explain  what  information  expressed  by  the  SADT  description  needs  to  be  formalized  using 
RML.  Then,  in  the  remainder  of  the  Chapter,  we  explain  the  steps  involved  in  deriving  an 
RML  model  from  the  SADT  description. 

S  J  Overview  of  the  SADT  Language 

We  now  give  an  overview  of  the  SADT  language.  (Some  of  this  section  is  extracted 
from  [Softechl],  either  directly  or  in  paraphrase.) 
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5  J.l  Models  of  systcms-composcd  from  diagranu 

SADT  is  a  method  for  helping  people  to  understand  complex  'systems',  defined  as  any 
combination  of  computer  hardware  and  software,  people  and  things,  structured  together  to 
perform  a  function.  The  system  may  be  a  new  system  to  be  built  or  an  existing  system,  and 
may  be  a  combination  of  computers,  people  and  things  or  may  consist  only  of  people  and 
things.  In  all  cases,  the  result  of  applying  SADT  is  a  'model'  that  shows,  by  a  series  of 
diagrams,  the  understanding  of  the  system  that  the  analyst  has  gained  as  a  result  of  its 
application.  For  new  system  building,  SADT  may  be  applied  in  planning,  analysis,  design, 
project  management,  or  wherever  a  model  is  useful  for  system  understanding. 

The  diagrams  in  a  model  are  organized  in  a  hierarchic  and  modular  fashion,  often 
called  'topnlown'.  That  is,  the  scope  of  the  system  is  established  in  a  single  overview  diagram. 
The  component  parts  shown  in  the  overview  are  then  detailed,  each  on  another  diagram. 
Each  part  shown  on  this  detail  diagram  is  again  broken  down,  and  so  forth,  until  the  system  is 
described  to  any  desired  level  of  detail.  Lower  level  diagrams,  then,  arc  detailed  breakdowns 
of  higher  level  diagrams.  At  each  stage  of  breaking  down  the  system,  the  higher-level  diagram 
is  said  to  be  a  'parent'  or  overview  of  the  lower  level  'detail'  diagram.  Sec  Figure  5-1. 


Figure  5-1 


In  an  SADT  diagram,  the  component  parts  are  shown  as  numbered  boxes.  A  diagram 
may  have  no  more  than  six  boxes. 
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Dual  eapccts:  data  and  activity 

(This  section  is  taken  from  [Softech2].) 

All  systems  are  analyzed  by  SADT  in  terms  of  two  major  aspects  —  their  things 
(objects  or  data)  and  their  happenings  (activities  performed  by  men,  machines,  computers, 
software,  etc.). 

These  aspects  are  always  examined  together.  However,  the  major  emphasis  can  be  on 
only  one  at  a  time.  Thus,  to  completely  describe  a  system,  SADT  calls  for  the  creation  of  two 
decompositions  —  an  'activity*  decomposition*  and  a  'data  decomposition*.  The  activity 
decomposition  shows  the  happenings  (as  activity  boxes),  and  the  things  that  interrelated  them 
(as  data  arrows).  The  data  decomposition  shows  the  things  of  the  system  (as  data  boxes),  and 
the  happenings  that  interrelated  them  (as  activity  arrows). 


A  COMPLETE  MODEL  HAS  TWO  DECOMPOSITIONS 
EACH  DESCRIBED  BY  THE  SAME  NOTATION. 


Figure  5-2 


In  spite  of  the  way  it  may  sound,  the  activity  decomposition  and  the  data 
decomposition  are  not  mirror  images.  Each  is  a  uniquely-structured  view  of  the  system.  Each 
portrays  the  system’s  operation  in  a  manner  that  the  other  cannot  duplicate.  Yet,  because 
they  both  describe  the  same  system,  they  are  interdependent.  The  complementary  activity  and 
data  decompositions  can  be  crossrchecked,  to  insure  that  applications  of  SADT  are  complete 
and  conastent.  See  Figure  5-2. 
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ACTIVITY  DLAGRAM 
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Figure  5-3 


5 J3  Dlagnnv-compoKd  from  bo^xet 

SADT  diagrams  consist  of  boxes  and  arrows,  and  text  describing  them.  The  notation 
is  kept  simple,  to  permit  easy  reading  with  little  special  training. 

In  SADT,  boxes  represent  components  in  the  breakdown,  and  arrows  represent 
relationships  between  these  components.  Descriptive  labels  are  written  inside  each  box  and 
along  each  arrow  to  describe  their  meaning.  Figure  5-3  gives  a  sample  SADT  diagram  from 
[Softechl]  The  boxes  represent  activities  and  the  arrows  represent  data  or  things  which  are 
the  interfaces  between  those  activities.  The  side  at  which  an  interface  arrow  enters  or  leaves 
a  box  shows  its  interface  role  as  an  input,  control,  output,  or  mechanism  for  the  box,  as  shown 

in  Figure  5-4. 
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BOX/INTERFACE  ARROV/  DEFINITION 


Input 


Figure  5-4 


The  input  data  (oa  the  left)  arc  transformed  into  output  data  (on  the  right).  Controls 
(on  the  top)  govern  the  way  the  transformation  is  done.  Mechanisms  (on  the  bottom)  indicate 
the  means  by  which  the  function  is  performed.  A  'mechanism'  might  be  a  person,  a 
committee,  a  machine,  or  a  process. 

5.2.4  Interfaces  between  boxes 

The  arrow  structure  on  an  SADT  diagram  represents  a  constraint  relationship  among 
the  boxes.  It  does  not  represent  flow  of  control  or  sequence.  The  arrows  entering  a  box  show 
all  that  is  needed  by  the  box  to  perform  its  function.  Therefore,  the  box  is  constrained  by  its 
input  and  control  arrows. 

An  output  of  one  box  may  satisfy  some  or  all  of  input  and  control  conditions  required 
by  one  or  more  other  boxes.  It  is  not  necessary  that  each  and  every  box  have  input  and 
control  and  output  and  mechanism  (see  [Ross77b]).  Also,  several  boxes  can  be  active 
simultaneously.  [1] 

The  arrow  label  describes  what  the  arrow  represents.  Arrows  may  branch  or  join. 
The  branches  may  each  represent  the  same  thing,  or  different  things  of  the  same  general  type. 
To  reduce  the  clutter  on  the  diagrams,  we  use  the  conventioa*  shown  in  Figure  5-5. 


[1]  There  are  apparently  no  restrictons  on  how  the  activations  of  the  component  boxes  relate 
to  the  parent  box. 
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Figure  5-5 


5^^  Interfaces  between  parent  and  detail  diagrams 

Most  arrows  arc  connected  at  both  ends  to  boxes  on  the  same  diagram.  Other  anos^s 
leave  one  end  unconnected.  These  unconnected  arrows  represent  inputs,  controls,  and 
outputs  of  the  parent  box  or  of  the  parent  diagram.  TTic  connections  for  these  arrows  can  be 
found  on  the  parent  diagram.  In  order  to  make  the  diagrams  complete  and  consistent,  all 
such  unconnected  arrows  must  show  their  continuation  on  their  parent.  See  Figure  5-^. 

Although  arrow  connections  from  parent  boxes  to  detail  diagrams  may  be  obvious 
from  the  labels,  a  special  notation,  called  ICOM  codes,  allows  readers  to  do  the  match 
quickly.  The  letter  I,  C,  O,  or  M  is  written  near  the  DDconnected  end  of  the  arrow  on  the 
detail  diagram,  to  identify  that  the  arrow  is  shown  as  an  Input,  Control,  Output,  or 
Mechanism  on  the  parent  box.  To  pinpoint  the  arrow  more  precisely,  this  letter  is  followed  by 
a  number  giving  the  relative  position  at  which  the  arrow  is  shown  entering  or  leaving  the 
parent  box,  numbering  left  to  right  and  top  to  bottom.  For  example,  'C3'  written  on  an  arrow 
in  the  detail  diagram  indicates  that  this  arrow  is  shown  as  the  third  control  arrow  entering  the 
parent  box.  These  identifications  are  written  on  the  maicbing  arrows  of  the  detail  diagram, 

5J..6  Reference  notation 

A  special  notation  is  provided  by  SADT  for  referencing  boxes.  The  boxes  on  a 
diagram  are  numbered  one  through  n,  where  n  is  the  number  of  boxes  (not  greater  than  six). 
The  place  of  each  SADT  diagram  in  a  model  is  indicated  by  a  'node  index',  derived  from  the 
numbering  on  the  boxes.  For  example,  the  diagram  with  node  index  A21  is  the  diagram  which 
details  box  1  on  the  A2  diagram.  Similarly,  node  A2  is  the  diagram  (hat  details  box  2  on  the 
AO  diagram,  which  is  the  'top'  of  the  model.  (Having  an  'A'  as  the  first  character  of  the 
expression  indicates  that  the  diagrams  describe  activities;  a  starring  letter  'O'  would  indicate 
data.)  The  diagrams  of  a  model  arc  ordered  by  their  node  index,  illustrated  in  Figure  5-7. 

For  a  given  diagram,  the  text  describing  it  makes  references  to  the  boxes  and  arrows  on  the 


-59- 


Figure  5-6 

diagram.  Because  the  text  is  associated  with  this  particular  diagram,  the  boxes  can  be  pointed 
to  by  using  just  the  box  number,  and  the  arrows  can  be  referenced  by  the  box  number  and  the 
ICOM  code  of  the  arrow.  For  example,  in  Figure  5-8,  '4C2'  refers  to  the  2nd  control  entering 
box  4. 


In  this  thesis,  we  will  use  a  different  notation  than  the  above  to  reference  the 
elements  of  an  SADT  model.  Our  notation  differs  only  slightly  from  that  in  [Koss77b].  We 
will  not  try  to  distinguish  between  "box  1  of  diagram  Ptl"  and  'diagram  A2r;  we  will  refer  to 
both  as  "node  A2r,  since  they  represent  the  same  concept.  As  shown  in  Figure  5-9,  the  same 
reference  expression  can  be  used  to  refer  to  an  arrow,  whether  on  the  parent  or  detail 
diagram. 

The  essential  difference  is  that  we  will  not  care  to  distinguish  an  'outerface*  from  an 
'innerface*.  While  they  refer  to  two  different  places  on  the  diagrams,  they  always  refer  to  the 
same  objects  in  the  RML  model. 
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Levels  of  Diagrams 


Corresponding  Node  Index 

A-0  Monitor  Project  (Top  Level  Context) 
AO  Monitor  Project 

A1  Establish.  Schedule 
A2  Update  File 

A.21  Build  Iviaster 
A22  Transcribe  Updates 
A23  Maintain  Records 
A24  Handle  Cb^anges 
■  A3  Report  Status 
A4  Review  Progress 


Figure  5-7 


5^.7  JoDcton 

The  points  on  an  SADT  diagram  where  arrows  meet  or  separate  will  be  called  junction 
points^  or  Junctors,  in  this  document.  Figure  5-10  shows  the  different  kinds  of  junction  points 
mentioned  in  [Ross77b]. 

Junction  points  give  SADT  a  distinctive  flavor  compared  to  box-and-arrow  languages 
that  allow  only  direct  connections  between  nodes.  This  SADT  arrow  structuring  allows  the 
interface  arrows  for  boxes  within  a  diagram  to  be  more  precisely  specified  by  allowing  the 
breakdown  of  an  arrow  into  more  specific  concepts  than  a  direct  arrow  connection  would  have 
shown.  In  effect,  simultaneous  decomposition  of  both  data  and  activity  is  allowed,  although 
the  primary  emphasis  is  on  the  boxes  rather  than  on  the  arrows. 
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Figure  5-8 


Figure  5-9 


Distribute 
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Branch 
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Bundle 


OR-Branch 


Figure  5*10 


However,  there  do  seem  to  be  some  guiding  principles  intended,  as  we  surmise  from 
[RossTTb].  First  of  all,  the  junction  points  represent  constraints,  not  control  flow  or  data  flow. 
(We  will  interpret  this  quite  literally  in  the  derived  RML  model  by  adding  assertions  to 
express  these  constraints.)  Second,  nothing  should  be  gained  or  lost  between  the  boxes;  that 
b,  nothing  should  'happen*  (in  the  case  of  activity  modeb)  between  the  boxes,  since  a  box  b 
supposed  to  be  'equal  to  the  sum  of  its  parts'.  (For  data,  we  might  surmise  that  no  'thing' 
should  exist  between  the  boxes  on  a  diagram.) 

SADT  arrows  are  to  be  thought  of  as  nested  cables,  or  conduits,  or  pipelines  as  shown 
in  Figure  5-11  (from  [Softech3]),  showing  vegetables  as  coosbting  of  root  crops  and  leaf  crops. 

In  [Ross77b],  Ross  mentions  'tying*  the  data  and  activity  together,  i.e.  cross- 
referencing  them,  to  check  consbtency  between  them.  One  possible  way  to  interpret  thb 
would  arise  from  considering  the  'arrow  inside  an  arrow'  relationship  and  the  'box  inside  a 
box'  relationship  to  express  the  same  thing.  Let  us  suppose  that  two  arrows,  X  and  XI  on  an 
activity  diagram  arc  such  that  XI  b  inside  X,  and  further  let  us  suppose  X*  and  XI’  are  boxes 
in  a  data  model  and  represent  the  same  concepts  as  arrows  X  and  XI,  respectively.  Then  box 
XI’  must  be  inside  box  X  (using  'inside'  recursively,  Xl’  b  cither  on  the  detail  diagram  of  X 


ARROW  BRANCHING 


(Note:  These  labels  are 
redundant,  and  may  be 
omitted, ) 


\ 


Vrjrfjtferrx 


•  the  entire  data  class 

may  be  on  both  branches. 


♦  only  a  sab-class  of  data 
may  be  on.  one  branch, 
and  the  complete  data 
class  on  the  other. 


U*f 


m 


or  the  data  class  may  be 
broken  into  sub -classes, 
with  each  sub -class  on  a 
separate  branch. 


Figure  5-11 

or  on  the  detail  diagram  of  one  of  its  subboxes). 
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J  More  OB  data  modelo 


SADT  data  modeU  consist  of  boxes,  representing  data,  interconnected  by  arrows 
representing  activities.  Aside  from  the  reversed  usage  of  boxes  and  arrows,  data  diagrams  are 
otherwise  identical  in  appearance  to  activity  diagrams.  The  roles  of  the  arrows  are  again 
called  Input,  Control  and  Output.  From  the  clues  present  in  [Ross77b],  one  can  determine 
that  the  input  activities  have  something  to  do  with  creating  the  'thing*  that  the  box 
represents;  control  activities  affect  the  thing  somehow,  and  output  activities  use  or  reference 
it. 

5  J.f  Ab  Example 

We  have  attempted  to  model  some  aspects  of  the  Cardiac  Pacemaker  Center  at  the 
Toronto  General  Hospital  (courtesy  of  Dominic  Cowey  and  associates).  The  pacemaker 
center  is  a  unit  of  TGH  which  receives  referrals  for  patients  who  intend  to  have  surgery  to 
place  a  cardiac  pacemaker.  The  pacemaker  center  is  re^>onsible  for  follow-up  of  patients  who 
have  received  a  pacemaker,  and  a  computer-based  system  is  currently  in  use  [DiMarco83]. 
Figure  S-12a  is  the  AO  diagram  of  one  view  of  the  activity  of  being  a  pacemaker  patient. 
Figure  S-12a*  is  the  accompanying  text,  more  or  less  in  the  style  of  SADT  as  described  earlier. 
In  lieu  of  other  diagrams,  some  of  the  relevant  information  that  one  would  normally  find  in 
related  diagrams  of  the  model  is  given  as  footnotes  in  Figure  5-12a’.  (Following  Figures  5- 12a 
and  S-12a’  are  two  more  figures,  5-12b  and  S-12c,  which  are  used  in  the  discussion  of  the 
example  to  follow.) 
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Figure  12a 

Activity  descriptions  BE  A  PACEMAKER  PATIENT 


A  patient  who  has  been  referred  by  his/her  physician  to  the  pacemaker 
center  (11)  must  make  an  appointment  (box  1)  before  signing  in  (box  2)  as  well 
as  before  all  subsequent  encounters,  which  include  assessments  (box  3)  and 
treatments  (box  4).  Making  an  appointment  (box  1)  depends  on  the  patient 
(ICl)  for  whom  the  appointment  is  being  made,  who  could  be  a  patient  just 
referred  (11),  a  patient  just  finishing  an  assessment  (301),  or  a  patient  just 
finishing  a  treatment  (401). 

The  patient  (211)  signs  in  to  become  officially  a  patient  of  the 
pacemaker  center  (201)  and  proceeds  directly  to  his/her  initial  assessment 
(311),  an  appointment  for  which  (3C1)  was  arranged  for  him/her  at  the  outset. 
[1]  The  result  of  an  assessment  is  an  assessed  patient  (302).  [2]  The  assessed 
patient  will  immediately  arrange  an  appointment  (301->  ICl)  for  the  next 
event  in  the  patient  lifecycle  as  a  pacemaker  center  patient,  whatever  is 
recommended  as  a  result  of  this  assessment.  The  next  event  could  be  a 
treatment  (301->411)  [3]  or  an  assessment  (301— >311).  Every  treatment  is 
followed  by  an  assessment  to  check  on  the  effects  of  the  treatment,  including 
the  case  of  post-mortem  analysis  if  the  patient  dies,  or  interviewing  the 
patient  in  the  case  where  the  patient  elects  to  leave  the  center.  In  these  cases, 
the  patient  is  considered  terminated  (Ol).  [4] 

Figure  5-12a* 


[1]  An  assessment  (box  3)  can  be  preoperative  (before  surgery)  or  postoperative;  might  concern 
the  patient’s  condition  or  that  of  the  patient’s  pacemaker;  might  be  in  the  clinic,  over  the 
telephone  (batteries  are  checked  this  way),  and  so  on.  Postmortem  analyses  are  also  included 
within  this  box. 

[2]  Considered  as  part  of  an  assessed  patient  is  information  about  doctors’  recommendations, 
including  a  recommended  next  appointment. 

[3]  e^.  surgery,  pacemaker  reprogramming. 

[4]  e.g.  lab  tests,  a  physical,  battery  checkup. 
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Figure  12b 

Activity  description  showing  junctors 
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Figure  12c 

Properties  of  junctor  constraints 


DlacontoD  of  the  cmnple 

When  SADT  is  used  for  requirements  definition,  all  of  the  information  needed  to 
express  the  problem  situation  is  supposed  to  be  included.  In  order  to  derive  an  RML  model 
from  the  SADT  description,  we  must  answer  these  questions: 

(1)  What  information  is  contained  in  an  SADT  diagram?  [1] 

(2)  How  do  we  formally  define  the  concepts  represented  by  the  labels  on  the  boxes 
and  arrows? 

(3)  How  do  we  formalize  all  of  the  information  in  the  accompanying  textual 
narration? 

Before  doing  this,  it  is  important  to  understand  just  what  is  NOT  in  an  SADT 
diagram. 

First  of  all,  let’s  look  at  activities.  We  have  seen  that  an  activity  box  with  its  impinging 
arrows  represents  some  kind  of  transformation  from  inputs  to  outputs  using  controls.  What 
does  this  mean  exactly?  When  is  the  activity  considered  'active'?  When  does  it  start  or  stop? 
When  are  the  inputs  consumed,  outputs  produced,  controls  used?  [2] 

What  about  data/things?  What  does  it  mean  that  the  'input  activities'  'create'  the 
thing?  What  do  the  'control  activities'  add  to  the  description? 

While  some  of  the  this  information  is  implied  by  the  general  meaning  of  the 
input/control/output  interfaces,  much  of  it  is  described  mainly  in  the  text  that  describes  the 
intention  of  the  diagram. 

What  do  the  arrow  junction  points  signify?  What  does  it  mean  when  arrows  'branch' 
or  'join'?  To  interpret  these,  one  usually  says  something  in  natural  language,  such  as 
'sometimes  the  patient  goes  next  to  a  treatment  and  other  times  to  an  assessment'.  Or  'some 
of  the  patients  do  this  while  others  do  that'.  Or  'the  appointment  is  for  only  one  of  the 
following:  initial  interview,  assessment,  treatment*.  Or  'the  input  to  the  assessment  is  either  a 
new  pacemaker  patient  or  a  just  treated  or  assessed  patient*. 

Perhaps  the  first  question  a  semantic/conceptual  model  would  have  asked  is  what  kind 
of  objects  does  the  model  represent:  a  generic  object  (class),  a  particular  instance,  a 
prototypical  instance?  At  the  SADT  level,  there  is  no  commitment  to  a  particular  kind  of 
semantic  model  in  this  sense;  one  is  only  concerned  about  how  the  subject  matter,  expressed 
in  the  embedded  language,  is  structured  to  achieve  effective  communication.  The  ability  not  to 


[1]  It  is  interesting  to  ask  whether  ALL  of  the  information  needed  to  determine  the  complete 
system  is  present  once  a  'completely  decomposed'  SADT  model  is  provided  (e.g.  is  it 
equivalent  to  Petri  nets  or  some  other  computational  model?).  I  do  not  address  this  question, 
but  rather  only  the  question  of  how  to  get  a  semantic  model  in  an  RML-like  language. 

[2]  In  practice,  activities  are  used  to  represent  any  kind  of  description  of  change;  in  addition 
to  Input  to  Output  transformations,  one  could  describe  a  process  (e.g.  operating  system)  that  is 
best  described  as  producing  periodic  outputs  using  mostly  controls  rather  that  inputs,  or  one 
could  intend  a  kind  of  'script'  of  the  behavior  of  some  entity  over  its  relevant  lifetime,  as  in 
the  pacemaker  patient  example. 
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make  a  commitment  to  these  things  while  introducing  all  the  relevant  concepts  is  an  essential 
feature  of  SADT  and  a  major  contributing  factor  to  its  general  utility  and  success,  but  in 
order  to  derive  an  RML  model,  we  will  have  to  make  a  commitment.  RML  allows  the 
precision  and  formality  to  make  these  statements. 

The  following  discussion  is  for  the  purpose  of  identifying  what  information  needs  to 
be  formalized  via  RML. 

S3  CoDilnictlnf  the  RML  model 

5J.1  Concept  definitions 

We  will  treat  an  RML  requirements  model  as  consisting  of  several  concept  models, 
where  each  SADT  (data  or  activity)  decomposition  corresponds  to  one  concept  model.  Each 
concept  model  has  a  'top',  or  'root',  which  is  represented  by  an  AO  or  DO  node. 

For  each  SADT  concept  model,  we  create  a  generic  concept  name,  which  is  the  name 
of  a  class  or  metaclass  in  the  requirements  model  As  an  example,  the  symbol 
PACE  MAKE  R_PATIENT  might  name  the  class  of  pacemaker  patients. 

5.3  J  Boxes  In  a  diagram 

For  each  box  in  an  SADT  diagram,  we  add  an  attribute  (property  name)  to  its  RML 
concept  dehnition.  These  will  be  part  attributes,  ix.  attributes  in  the  part  property  category 
of  RML.  In  practice  we  would  choose  mnemonic  identifiers  as  attributes,  but  here  we  will 
just  use  the  SADT  node  numbers  (remembering  that  they  should  actually  be  prefixed  with  the 
concept  name  to  distinguish  them  from  attribute  names  generated  from  other  SADT  models). 
For  Figure  S-12a,  the  part  attributes  would  be  Al,  A2,  A3,  and  A4. 

We  will  let  AO  correspond  to  the  special  RML  self  attribute,  which  stands  for  any 
instance  of  the  named  class  or  metaclass.  We  will  also  use  the  'dot'  notation  for  attribute 
selection,  so  that  A3A32  is  the  second  part  of  the  third  part  of  AO.  Note  that,  in  keeping 
with  the  usage  of  'self',  for  which  AO  is  used  here,  we  assume  every  dot  expression  to  be 
prefixed  by  AO,  so  A3A32  is  equivalent  to  A0A3A32.  Also,  note  that  in  our  way  of  naming 
attributes  by  node  numbers,  'A32'  would  be  the  name  of  the  second  attribute  of  A3.  [1] 

For  each  part,  we  supply  the  generic  concq)t  name  of  some  model,  thus  forming  a 
definitional  property  by  supplying  a  'definitional  property  value'  to  each  attribute.  For  the 
example  in  Figure  5-12a,  this  would  yield  the  following  definitional  properties  for 
BE_A_PACEMAKER_CENTER_PATIENT: 


[1]  Although  it  looks  as  though  A3A2  would  do  instead  of  A3A32,  we  use  the  latter  to 
emphasize  that  this  A32  attribute,which  is  the  second  part  of  A3  would  be  distinct  from  A2, 
which  is  the  attribute  for  the  second  part  of  AO. 
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parts 

AlrMAKE  APPOINTMENT 
A2:  SIGN_»l 
A3:  GET  ASSESSED 
A4:  GET  TREATED 


One  should  note  here  that  the  definitional  property  values  (MAKE_APPOINTMENT,  etc.)  are 
RML  class  names,  as  distinct  from  the  English  labels*  in  the  diagrams. 

In  a  manner  similar  to  that  for  the  single  dot  notation,  we  have  the  double  dot 
notation,  which  links  definitional  property  values,  so  that,  for  example, 
PACEMAKER_PATIENT  •  •  D2  •  •  D24  is  the  definitional  property  value  for  the  fourth  part 
of  the  second  part  of  PACEMAKER_PATIENT. 

53  J  Boundary  arrows 

Now,  for  each  input,  control,  and  output  arrow  of  the  root  node,  we  add  a 
corresponding  property,  ijc.  attribute  plus  definitional  property  value.  (As  for  the  part 
properties,  we  will  use  the  simplest  ICOM  codes  in  the  context  of  the  diagram  instead  of  the 
actual  mnemonic  identifiers  that  might  be  used  in  RML  modeling  practice.)  For  the  example, 
this  yields: 


Input 

II:  REFERRED_PATIENT 
control 

Cl:  PACEMAKER_CENTER 

output 

Ol:  TERMINATED_PATIENT 


Recall  that  in  RML  these  properties  specify  that  the  input  will  be  removed  from  its  property 
value  class,  the  control  will  not  be  removed  by  any  action  of  this  activity,  and  the  output  will 
be  inserted  into  its  property  value  class  during  the  activity. 

We  can  refer  to  arrows  of  a  diagram  as  properties  of  the  parts  of  which  they  serve  as 
interfaces,  rather  than  referring  to  them  directly  as  properties  of  the  root  node.  So,  we  refer 
to  control  3  of  node  A24  as  A24.C3  (which  is  really  AO  A2A24.C3). 

53.4  Arrow  connections 

As  described  above,  the  ICOM  points,  ix.  the  boundary  points  on  boxes,  correspond 
to  RML  attributes.  Now  consider  the  meaning  of  an  arrow  connecting  two  such  boundary 
points.  Take  for  example  an  arrow  connecting  the  output  Ol  of  one  box  to  the  input  II  of  a 
second: 
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pi:  Cl 
p2:C2 
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This  will  always  mean  (at  least)  that 

C«  •pl»  •01  =  C«  •pZ*  •II, 

ix.  that  the  definitional  property  values  for  the  tail  and  the  head  of  the  arrows  are  the  same 
class.  This  records  the  structural  information  (1]  conveyed  by  the  SADT  diagram.  Another 
example  would  be: 


ports 


pi. Cl 


Constraints  can  be  added  to  the  definitions  to  describe  the  ^>ecific  nature  of  the 
relationship  between  the  boxes  on  the  diagrams.  In  Figure  5-13, 

constraint  same:  pl^Ol  =  p2^Il 

says  [2]  that  pi’s  output  is  always  the  same  as  p2’s  input.  This  is  a  rather  strong  constraint:  if 
pi  is  nothings  then  its  01  property  value  is  also  nothings  and  therefore  p2  •  II  must  be  nothing 
if  p2  itself  is  not  nothing.  This  says,  in  simpler  terms,  that  if  pi’s  output  is  to  be  available  to 
p2,  the  communication  must  take  place  at  a  time  when  both  parts  are  active. 

If,  instead,  we  wanted  to  express  the  'looser'  constraint  that  'the  output  of  pi  is  the 
input  to  p2'  but  without  requiring  the  concurrent  existence  of  the  two  parts,  then  we  could 
write: 

PVAL(p2J[l,t)=z  implies  [3  s  (s<  t)  A  PVAL(pl,01,s)=2] 
which  says  that  any  input  to  p2  was  at  some  prior  time  an  output  of  pi.  In  Figme  5-15  are  two 
assertion  classes  and  a  metaclass  for  later  use  in  expressing  such  constraints. 

We  have  used  the  assertion  metaclass,  SAME_RANGE_AT_BOTH_ENDS,  to  assert  that  the 
head  and  tail  definitional  property  values  are  the  same. 


[1]  'definitional'  information  in  RML  jargon 

[2]  This  translates  to  M  [fpv(pl,01,t)=fpv(p241,t)]  in  the  FOL 
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SAME_RANGE_AT_BOTH_ENDS  in  CLASS  isa  ASSERTION_CLASS  with 

part 

same-range:  SELF  •  •head  =  SELF  •  •tail 

ARROW_CONNECTION  in  SAME_RANGE_AT_BOTH_ENDS  isa  ASSERTION_CLASS  with 
constraint  same:  pi  •  01  =  p2  •  II 

DATAFLOW  in  SAME_RANGE_AT_BOTH_ENDS  with 
argument 

taU:  OBJECT 
head:  OBJECT 

constraint 

same:  PVAL(head  Jl,t)=z  implies 

Ps  (s<t)  A  PVAL(taU,OU)=z] 

Figure  5-15 

For  the  diagram  of  Figure  5-12a,  the  arrow  constraints  will  be  given  after  the  section 
on  junctors,  since  most  of  the  arrow  segments  involve  at  least  one  junctor. 

53S  Junctors 

There  can  be  a  lot  of  junction  points  (junctors)  on  a  diagram.  We  will  interpret  them 
as  representing  classes  of  simple  constraints  in  RML.  It  is  quite  advantageous  to  be  able  to 
ignore  details  of  these  kinds  at  first,  and  SADT  allows  one  to  ignore  them.  Then,  part  of  the 
process  of  deriving  an  RML  model  from  the  SADT  model  is  to  q)ecify,  for  each  junctor,  what 
kind  of  constraint  it  represents.  There  are  usually  quite  a  few  junctors  to  specify,  but  each  is 
usually  a  simple  constraint. 

For  each  junction  point,  we  give  a  property  to  the  node  on  whose  diagram  the 
junction  points  appear.  The  definitional  property  value  will  be  an  RML  assertion  class. 
Below,  we  will  first  define  some  classes  of  constraints  that  can  be  used  to  interpret  junctors. 
Then  we  will  use  them  to  specify  the  constraints  intended  in  Figure  5-12a*,  the  narration  of 
Figure  5-12a. 

We  will  label  the  junction  points  Jl,  J2,...,  as  shown  on  Figure  5'12b,  and  let  these 
symbols  also  be  the  property  names  in  the  requirements  model  belonging  in  the  constraints 
property  category.  This  is  all  shown  schematically  in  Figure  5-16. 

BE_A_PACEMAKER_PATIENT 

constraints 

Jl: 

J2: 


Figure  5-16 


5  J  J.l  Junctor  Constrnlnts 

The  assertion  class  serving  as  a  definitional  property  value  will  have  three  arguments, 
one  for  each  of  the  arrow  segments  that  connect  to  the  corresponding  junction  point  on  the 
diagram.  The  argument  attributes  correspond  to  the  incoming  and  outgoing  arrows  and  are 
called  in/outiyout2  for  branching  points  and  inl/in2/out  for  joining  points.  The  most  general 
constraints  simply  specify  the  arguments.  See  Figure  5-17.  The  junctors’  adjoining  arrows  are 
labeled  with  the  attribute  names  on  Figure  5-12c. 

BRANCH_CONSTRAINT_l  in  BRANCH_CONSTRAINT_CLASS_l  isa  ASSERTION  with 
argn  meats 
in:  CLASS 
outl:  CLASS 
out2:  CLASS 

JOIN_CONSTRAINT_l  in  JOIN_CONSTRAINT_CLASS_l  isa  ASSERTION  with 
argo  meats 

ini:  CLASS 
ini:  CLASS 
out:  CLASS 


Figure  5-17 


It  is  evident  from  examples  (see  Figure  5-12a)  that  an  ISA  relationship  is  often  appropriate 
between  the  in-  and  out-  arguments  of  a  junctor.  The  assertion  metaclasscs  in  Figure  5-18 
associate  some  interesting  constraints  to  their  instances. 

The  first  metaclass,  BRANCH_CONSTRAINT_CLASS_l,  specifies  that  its  instances  (of  which 
BRANCH_CONSTRAINT_l  is  one)  are  such  that  the  output  definitional  properties  are 
^ccializations  of  the  input  definitional  property,  as  is  the  case  for  J9  of  Figure  5- 12c,  which 
separates  terminated  patients  from  other  assessed  patients.  The  'covers'  property  says  that 
every  in-value  must  be  in  at  least  one  of  the  out-arrow  classes.  [1]  The  third  metaclass, 
BRANCH_CONSTRAINT_CLASS_2,  specifies  that  its  instances  have  the  same  class  as  the  in- 
and  out-  definitional  property  values,  as  is  the  case  for  points  J1  (REFERRED_PATIENT) 
and  Jll  (TREATED_PATIENT)  in  Figure  5-13c.  Note  that 
BRANCH_CONSTRAINT_CLASS_2  in  CLASS  isa  BRANCH_CONSTRAINT_CLASS_l. 
We  can  specialize  BRANCH_CONSTRAINT_CLASS_l  in  a  different  way  by  specifying  that 
the  ^>ecializations  are  disjoint  classes;  this  is  specified  as  BRANCH_CONSTRAINT_CLASS_3 
above.  The  constraint  class  for  point  J9  would  actually  belong  in  this  metaclass  because 
terminated  patients  form  a  class  that  is  disjoint  from  the  class  of  assessed  patients  for  whom  a 
different  kind  of  appointment  is  made. 

Some  specializations  of  BRANCH_CONSTRAINT  will  be  useful.  They  are  shown  in 
Figure  5-19. 

For  an  instance  of  IDENTICAL_BRANCH_CONSTRAINT,  the  value  on  the  out-arrows  will 
always  be  the  same  as  the  value  on  the  in-arrow.  An  instance  of  BRANCH_&_SPECIALIZE 
asserts  that  the  in-value  is  the  same  as  at  least  one  of  the  out  values  while 
BRANCH_&_SPECIALIZE_EXCLUSIVE  asserts  that  exactly  one  out-arrow  has  a  matching 
value. 


[1]  I.e.,  the  in-class  is,  in  a  sense,  the  'least  upper  bound'  of  the  two  out-classes. 
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BRANCH_CONSTRAINT_CLASS_l  in  CLASS  ha  ASSERTION_CLASS  with 

constraint 

outl*isa*in:  ISA(5£LF  •  •outl^ELF  •  nin) 
out2-isa-in:  ISA(5£LF  •  •  out2 ,5£L£  •  •  in) 
covers:  Forail  x  in  SELF  •  •  in 

[IN(x^£L£  •  Ooutl)  or  IN(x^£££  •  Oout2)J 

BRANCH_CONSTRAINT_CLASS_2  in  CLASS  ha  BRANCH_CONSTRAINT_CLASS_l  with 

constraint 

samel:  SELF  •  oin  =  SELF  •  noutl 
same2:  SELF  •  •  in  =  SELF  •  •  out2 

BRANCH_CONSTRAINT_CLASS_3  in  CLASS  ha  BRANCH_CONSTRAINT_CLASS_l  with 

constraint 

disjoint:  IN(x^£££  •  Ooutl)  iff  IN(x^£LF  •  •out2) 

JOIN_CONSTRAINT_CLASS_l  in  CLASS  ha  ASSERTION_CLASS  with 
constraint 

inl-isa-out:  ISA(5£L£  •  •inl^£LF  •  nout) 
in2-isa-out:  ISA(5£L£  •  •in2^£££  •  Oout) 

JOIN_CONSTRAINT_CLASS_2  in  CLASS  ha  JOIN_CONSTRAINT_CLASS_l  with 

constraint 

samel:  SELF  •  •  ini  =  SELF  •  •  out 
same2:  SELF  •  •  in2  =  SELF  •  •  out 

JOIN_CONSTRAINT_CLASS_3  in  CLASS  ha  JOIN_CONSTRAINT_CLASS_l  with 
constraint 

disjoint:  IN(x^£££  •  •  ini)  if  f  IN(x^£L£  •  •  in2) 

Figure  5-18 

An  instance  of  DATAFLOW_BRANCH_CONSTRAINT  asserts  not  an  equality  but  rather 
that  any  value  on  the  out-arrows  must  have  come,  perhaps  at  a  prior  time,  from  the  in-arrow. 
The  constraint  for  DATAFLOW_BRANCH_CONSTRAINT  says  the  same  thing  as  if  there 
were  two  arrows,  one  from  pi  to  p2  and  another  from  pi  to  p3,  each  with  the  DATAFLOW 
constraint  defined  above.  So,  we  could  rewrite  this  assertion  class  definition  as  follows: 

DATAFLOW_BRANCH_CONSTRAINT  ha  BRANCH_CONSTRAINT  with 
constraints 

flowl:  DATAFLOW  (tail:  pi,  head:  p2) 
flow2:  DATAFLOW (tail:  pi,  head:  p3) 


Some  more  useful  assertion  classes  are  shown  in  Figure  5-20. 

The  first  one  asserts  that  the  out-arrow’s  value  comes  from  either  of  the  in-arrows,  and  the 
second  is  a  specialization  of  the  first,  adding  a  requirement  that  the  first  value  of  the  out- 
arrow  comes  from  ini  and  later  values  come  from  in2.  This  constraint  will  be  used  for  junctor 
J2,  for  example,  in  Figure  5- 12b. 
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IDENTICAL_BRANCH_CONSTRAINT  in  BRANCH_CONSTRAINT_CLASS_2 

isa  BRANCH_CONSTRAINT  with 

constraints 

alwayvsamc:  ml=outl  and  iiil=out2 

BRANCH_&_SPEC1ALIZE  in  BRANCH_CONSTRAINT_CLASS_l 
isa  BRANCH_CONSTRAINT_l  with 

coaMralnt 

tl-lcast-onc:  in=outl  or  in=out2 

BRANCH_&_SPECIALIZE_EXCLUSrVE  in  BRANCH_CONSTRAINT_CLASS_l 
isa  BRANCH_CONSTRAINT_l  with 
cooatraliit  /*  Note:  inherits  'at-least-one'V 
exactly-one:  and  not  [in=outl  and  in=out2] 

DATAFLOW_BRANCH_CONSTRAINT  in  BRANCH_CONSTRAINT_CLASS_2 
isa  BRANCH_CONSTRAINT  with 

conMralnts 

flows: 

Forall  s 

PVAL(pl,01^)=2  implies 
{3 1  [ss  t  PVAL(p241,t)=2] 
and  3  t  (sst  and  PVAL(p341,t)=2D 

Figure  5-19 

JOIN_SPECIALIZATION_CONSTRAINT  in  JOIN_CONSTRAINT_CLASS_l 

isa  JOIN_CONSTRAINT_l 

JOIN_CONSTRAINT_WITH_INIT  isa  JOIN_SPECIALIZATION_CONSTRAINT  with 
constraint 

output-froin-inl-first-then-froin-in2: 

Exists  s 

[PVAL(se//  ,out^)=PVAL(je//  4nU)l 
and 

Exists  t  [(s<  t)  and 

PVAL(re//  ,out,t)=PVAL(je//  4n2,t)l 
JOIN_SPECIALIZED_WITH_INIT 

isa  J0IN_SPECIALIZATI0N_C0NSTRAINT40IN_C0NSTRAINT_WITH_INIT 

Figure  5-20 


Jonctor  constraints  In  the  ::xamplc 

The  junctor  constraints  in  the  example.  Figure  5- 12c,  are  listed  below. 
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Jl:  IDENTICAL_BRANCH_CONSTRAINT(m:  II,  outl:  J2  •  ini,  out2:  P2  •  II) 

J2:  JOIN_CONSTRAINT_WITH_INIT(ml:  Jl •  outl,  in2:  JIO •  out,  out:  pi •  Cl) 

J3:  BRANCH_&_SPECIALIZE_EXCLUSIVE(in:  Pl«  Ol,  outl:  P2« Cl,  out2:  j4« in) 

J4:  BRANCH_&_SPECIALIZE_EXCLUSIVE(in:  J3» out,  outl:  P3« Cl,  out2:  P4» Cl) 

J5:  JOIN_SPECIALIZED_WITH_INIT(inl:  P2« Ol,  in2:  J6» out,  out:  P3» II) 

J6:  JOIN_SPECIALIZATION_CONSTRAINT(inl:  Jll*out2,  i!i2:  J7«outl,  out:  J5»in2) 
J7:  BRANCH_AND_SPECIALIZE_EXCLUSIVE(in:  J8  •  out2,  outl:  J6  •  m2,  out2:  P4  •  II) 
J8:  BRANCH_AND_SPECIALIZE_EXCLUSIVE(in:  P3«  Ol,  outl:  J9» in,  out2:  J7* in) 
J9:  BRANCH_AND_SPECIALIZE_EXCLUSIVE(in:  J8»outl,  outl:  JIO* ini,  out2:  Ol) 
JIO:  JOIN  SPECIALIZED_CONSTRAINT(inl:  J9* outl,  in2:  Jll •  outl,  out:  J2 •  ini) 

Jll:  BRANCH_CONSTRAINT(in:  P4*  Ol,  outl:  JIO*  in2,  out2:  J6  *  ini) 


53^  Aaertlonf  for  farther  wnumtlci 

To  express  more  of  the  semantics  of  a  concept,  we  associate  assertions  to  the 
requirements  model  generic  concept  through  definitional  properties  in  several  property 
categories,  namely:  actcond,  termcond,  prccond,  and  postcond.  In  addition,  there  may  be 
additional  constraliit  properties  for  expressing  constraints  in  general  between  components  of  a 
model.  [1] 

Some  of  the  conditions  for  the  example  are  as  follows: 
actcond 

arrival:  II  ^  nothing 
precond 

referring-physician-authorized?:  AUTHORIZED(Il*  referring-phys) 
poftcond 

possibilities:  QUIT(Ol)  or  TRANSFERRED(Ol)  or  DIED(Ol) 


53,7  A  Note  on  SADT  and  Isa  hierarchies 

It  would  be  useful  to  have  an  SADT  notation  to  designate  ISA  relationships  between 
concepts.  Even  before  RML  objects  and  relationships  are  introduced,  it  would  be  useful  to 
indicate  one’s  intention  that  two  boxes  be  related  by  ISA,  i£.  in  such  a  way  that  all  the 
properties  (eventually  specified)  of  one  are  to  be  inherited  by  the  other.  When  one  concept, 
expressed  in  an  SADT  diagram,  is  considered  a  q>ecialization  of  the  another  and  inherits  its 
properties  (inputs,  outputs,  controls,  and  also  the  decomposition-parts,  interconn^tions  and 
junctors).  The  SADT  mechanism  arrows  can  be  used  to  represent  the  ISA  relationships.  This 
is  not  what  Ross  specifically  says  these  arrows  mean;  rather,  this  is  one  (convenient) 
interpretation  we  could  impose  to  get  a  correspondence  with  RML. 


[1]  Examples  of  these  general  constraints  could  be  mutual  exclusion  between  parts,  or  any 
other  assertion  whose  arguments  come  from  the  diagram  in  question. 
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Figure  5-21a  shows  the  ease  'A  supports  B'  (in  SADT-speak),  indicated  by  the 
upward-pointing  arrow,  which  in  RML  will  signify  that  A  ISA  B.  Concept  A  inherits  all  of 
the  properties  of  B,  and  this  should  be  evident  from  examining  A  and  B  in  the  context  of  any 
diagrams  they  appear  in.  Figure  5-21b  shows  a  case  where  there  is  multiple  inheritance. 
Attributes  must  be  matched  up  between  subclass  and  superclasses,  in  Figure  5-21b,  I  have 
indicated  only  a  few  input  arrows  to  illustrate  this  point.  For  box  A,  the  II  arrow  is  inherited 
from  Bl,  the  12  arrow  is  inherited  from  both  B1  and  B2,  and  13  is  a  new  property.  The  labels 
on  the  arrows  should  (informally,  in  English)  be  'sensibly*  relate-d,  i.c.  AJl  could  be 
synonymous  to  or  more  specialixed-sounding  than  BlJl,  and  AJ2  should  be  synonymous  to  or 
more  specialized -sounding  than  both  B1J2  and  B2il.  In  RML,  this  correspondence  becomes, 
more  formally,  the  inheritance  constraint  for  ISA,  which  says  that  the  definitional  property 
values  for  these  properties  can  be  the  same  as  or  more  specialized  than  the  ones  above. 

Figure  5-22  shows  the  case  'A  calls  B',  indicated  by  the  downward-pointing  arrow,  in 
which  one  box  'calls'  a  more  specialized  box  when  a  certain  condition,  here  a,  holds.  (An 
example  would  be  where  A  is  PERSON  and  B  is  CHILD  and  a  is  'age<14'.)  Clearly,  only 
proper  specializations  can  be  'called'. 

5.3,7.1  Consistency  rules 

The  constraints  enforced  as  a  result  of  inheritance  in  the  above,  when  interpreted  in 
terms  of  the  SADT  diagrams,  say  a  lot.  For  example:  If  A  ISA  B,  then  every  path  of  B  can  be 
overlaid  on  a  path  of  A  that  contains  the  same  (boundary  and  junction)  points,  in  the  same 
order.  The  subclass  can  have  additional  points  along  the  'inherited'  paths  and  possibly 
additional  paths.  This  rule  is  much  more  rigorous  than  the  more  'static'  usual  rule,  and  it 
suggests  additional  rules  for  RML.  (I  would  expect  the  SADT  diagrams  to  be  an  intuitive  aid 
helping  both  to  state  these  constraints  and  to  find  algorithms  for  checking  them.) 

Also,  the  cross-reference  checks  mentioned  earlier  between  data  and  activity  diagrams 
become  much  richer  when  these  paths  are  considered. 

5J.8  SADT  NoUdon  for  RML  Notions 

Already  above,  in  discussing  ISA  for  example,  we  have  suggested  that  some  RML 
notions  can  be  represented  graphically  in  SADT.  One  could  consider  how  diagram  assertions, 
for  example.  SADT  diagram  notation,  where  parts  are  boxes  in  a  diagram,  data  arguments  are 
Controls  arrows  and  triggering  conditions  are  Input  arrows,  and  so  on.  This  is  not  important 
to  the  thesis,  but  is  an  possible  consideration  in  developing  the  framework  further. 
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(a) 


(b) 


Figure  5-21 


A  calls  B  (which  presupposes  "B  isa  7^") 

5  “  2.  i 
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CHAPTER  6 
CONCLUSION 


(.1  Sommary  and  Contrlbatloiu 

The  research  reported  in  the  thesis  is  one  of  a  few  initial  efforts  to  argue  for  and 
demonstrate  the  usefulness  of  conceptual  world  modeling  in  Software  Engineering.  We  have 
concentrated  on  the  area  of  requirements  definition,  because  this  is  the  Software  Engineering 
activity  where  the  information  to  be  captured  in  the  conceptual  model  is  most  appropriately 
gathered  and  documented.  We  have  motivated  the  use  of  a  world  model  for  requirements 
definition  based  on  the  need  to  explicitly  document  definitions,  assumptions,  and  constraints 
that  arise  in  the  application  domain  of  discourse  but  are  usually  left  out  of  requirements 
documentation  because  of  the  lack  of  suitable  languages  that  are  able  to  capture  them. 

Requirements  research  and  development  has  until  recently  been  dealt  with  mostly  in 
the  practitioner’s  domain,  and  there  have  been  complaints  to  the  effect  that  the  basic  nature 
of  requirements  are  not  well-understood  and  should  receive  attention  from  academia.  This  is 
what  motivated  the  current  research. 

The  three  main  areas  addressed  in  the  thesis  are: 

1.  The  design  of  an  appropriate  language  for  requirements  modeling. 

2.  Formalization  of  the  requirements  language. 

3.  Methodology  for  constructing  the  requirements  model. 

The  contributions  with  req)ect  to  these  three  areas  are  discussed  below. 

(.1.1  Reqolrcments  Modeling  Language 

We  have  designed  RML,  a  language  for  requirements  modeling.  It  has  characteristics, 
such  as  being  object-oriented  and  making  use  of  abstraction  techniques,  that  are  popular  in 
database  management  and  Artificial  Intelligence,  and  apply  equally  well  to  requirements 
modeling,  because  they  are  particularly  well-suited  to  the  organization  of  large  descriptions 
that  need  to  be  understood  by  humans. 

In  data  modeling,  the  purpose  of  modeling  languages  (including  the  entity-relationship 
approaches)  has  been  to  give  a  specification  of  a  database  rather  than  a  model  of  some 
(application)  world.  The  area  of  Corporate  Requirements  [Lum79],  which  for  the  database 
area  relates  closely  to  the  goals  of  the  thesis,  requires  the  more  world-oriented  modeling  that 
RML  provides.  In  this  direction,  the  more  recent,  so-called  semantic  data  models  aim  to 
better  capture  world-oriented  information,  but  they  at  best  mix  the  two  goals  of  world- 
oriented  and  database-oriented  modeling.  Two  weaknesses  of  data  models  are  their  facilities 
for  modeling  the  behavior  of  objects  over  time  and  expressing  constraints  of  various  kinds 
within  the  model.  RML  provides  these  needed  facilities,  giving  equal  treatment  to  all  three 
kinds  of  units. 
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The  object-oriented  nature  of  RML  and  the  abstraction  mechanisms  (especially  ISA 
hierarchies)  owe  a  lot  to  the  area  of  knowledge  representation  in  Artificial  Intelligence.  The 
components  of  the  RML  framework  are  to  be  found,  for  example,  in  PSN  [Levesque79].  We 
have  drawn  a  parallel  between  the  task  of  requirements  definition  and  the  construction  of  a 
knowledge  base,  observing  that  both  activities  require  direct  and  natural  modeling  of  the 
world.  Workers  in  Artificial  Intelligence,  e.g.  on  expert  systems,  must  deal  with  the  issues  of  a 
methodology  for  model  construction,  and  acquisition  of  knowledge  from  experts  is  a  major  job 
in  the  building  of  knowledge-based  systems.  We  claim  that  it  is  advantageous  to  view 
Software  Engineering  in  general  as  the  construction  of  knowledge-based  systems, 
independently  of  whether  the  purpose  of  the  system  has  anything  to  do  with  'artificial 
intelligence*  or  not.  We  point  out  also,  that  the  analogy  between  requirements  modeling  and 
a  knowledge  base  will  in  the  future  allow  solutions  to  problems  such  as  consistency  of  models, 
etc.  to  be  borrowed  from  AI. 

RML  is  compatible  with  Taxis,  a  language  for  the  design  of  information  systems, 
which  paves  the  way  for  extending  the  Taxis  approach  to  system  development  to  a  unified 
software  engineering  methodology  [Greenspan83]. 

Specific  contributions  arise  from  the  unique  characteristics  of  RML. 

Human-engineering 

All  objects  -  entity,  activity,  assertion  -  are  treated  uniformly  with  respect  to  the  framework. 
Property  categories  and  other  notational  devices  serve  to  make  the  language  more  usable. 
This  is  one  of  the  reasons  RML  is  more  appropriate  than  FOL  for  modeling. 

Assertions 

We  have  motivated  assertions  as  being  especially  appropriate  for  a  requirements  language, 
because  'constraints'  form  an  important  part  of  the  information  to  be  captured.  Treating 
assertions  as  objects  is  especially  novel  and  is  the  key  to  several  advantages  of  RML,  discussed 
below.  Two  important  points  with  respect  to  assertions  are: 

a.  Organization  of  assertions  ~  the  grouping  of  true  statements  into  classes  and 
metaclasses,  and  their  organization  using  ISA  hierarchies,  and 

b.  Roles  for  assertions  -  their  use  as  property  values  in  roles  such  as  invariants, 
preconditions,  postconditions,  triggers,  and  so  on. 

The  usual  treatment  of  information  in  these  roles  by  requirements  languages,  when 
the  information  is  present  at  all,  is  either  (a)  natural  language  comments,  or  (b)  named 
conditions,  which  can  be  cross-referenced  (as  in  PSL);  the  closest  thing  to  the  use  of  assertions 
in  a  requirements  language  is  a  proposal  by  [Agusa82]  which  adds  binary  relations  as  simple 
assertions  to  PSL.  RML  is  the  only  requirements  language  that  has  full  First-Order  Logic  for 
making  assertions,  while  structuring  a  model  (including  the  assertions)  according  to 
abstraction  principles. 

In  addition  to  the  advantages  of  organizing  assertions  with  regard  to  the  assertions 
themselves,  advantages  accrue  for  entities  and  activities  as  well.  The  usual  meaning  of  ISA 
organization  of  entities  is  intended  to  explain  inheritance  of  entity  'parts*  of  the  entity  object. 
Here,  however,  inheritance  is  extended  to  all  (definitional)  properties,  including  those  with 
assertions  as  value.  Thus,  for  example,  initial  conditions  and  invariants  for  entity  classes  are 
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inherited  by  subclasses  according  to  the  normal  rules  for  property  inheritance  (according  to 
which  the  re^)ective  assertions  may  be  restricted/strengthened  and  additional  assertion- 
inducing  properties  added),  significantly  extending  the  influence  of  ISA  hierarchies  for 
entities;  in  other  words,  declaring  two  entity  classes  as  ISA  related  is  a  much  stronger 
statement  when  assertions  are  present. 

The  ISA  hierarchy  for  assertions  has  implications  for  activities  as  well.  Since  the  ISA 
constraints  must  apply  to  assertion-inducing  properties  such  as  preconditions  and 
postconditions,  two  ISA  related  activity  classes  must  be  such  that  the  instances  of  the  subclass 
have  at  least  the  effects  of  instances  of  the  superclass  (since  each  occurrence/instance  of  the 
subclass  must  be  an  occurrence  of  the  superclass).  This  is  automatically  the  case  since  these 
conditions  can  only  be  restricted/strengthened  according  to  the  ISA  constraints. 

It  is  interesting  to  compare  this  situation  to  the  case  for  (database)  transactions  in 
Taxis,  where  the  enforcement  of  the  'dynamic  ISA  constraint'  for  transactions 
[MylopoulosSOb],  which  ensured  that  the  side-effects  specified  by  a  transaction  class  included 
the  side-effects  specified  by  its  superclasses,  had  to  be  stated  OUTSIDE  the  Taxis  language, 
namely  in  the  formal  semantics,  while  for  RML  this  constraint  is  automatically  satisfied  by  the 
normal  inheritance  mechanism  without  further  ado.  The  difference  between  RML  and  Taxis 
is  that  Taxis  preconditions  and  postconditions  are  not  assertions  per  le,  but  are  executable 
expressions  whose  semantics  are  tied  to  the  state-transition  meaning  of  evaluating  the 
expressions. 

Since  RML  has  assertions  as  objects,  one  can  relate  assertions  to  each  other,  e.g.  by 
expressing  that  two  assertions  are  never  true  at  the  same  time.  (This  is  done  with  an  assertion 
having  two  assertions  as  arguments.) 

The  closest  modeling  scheme  to  RML  in  this  respect  is  CSDL  [Roussopoulos79],  in 
which  structures  called  'frames'  are  organized  on  an  ISA  hierarchy.  A  frame  is  a  graphical 
representation  of  a  many-sorted  FOL,  and  therefore  the  CSDL  organization  of  frames  is 
actually  an  organization  of  FOL  assertions  (which,  unlike  RML,  takes  into  account  some 
forms  of  quantification  in  the  organization).  However,  CSDL  differs  in  several  ways  from 
RML,  especially  in  the  use  of  three  main  object  categories  with  their  respective  property 
categories. 

Modeling  of  Time 

As  pointed  out  by  [BubenkoSO],  modeling  time  is  extremely  important  in  expressing  real-world 
constraints.  The  features  for  modeling  of  time  that  have  been  designed  in  RML  combine  a 
model  for  clockycalendar  time  that  is  in  the  same  spirit  as  that  of  [BubenkoSO]  with  the 
framework  of  [AllenSl]  for  representing  knowledge  about  time  intervals.  The  model  is 
somewhat  more  general  than  [BubenkoSO]  since,  in  our  approach,  all  time  intervals,  not  only 
those  consonant  with  the  marks  on  a  clock  or  calendar,  are  organized  into  classes,  and  also, 
Bubenko  does  not  make  use  of  an  ISA  hierarchy.  The  use  of  Allen’s  framework  provides  a 
calculus  for  time  intervals  as  well  as  some  background  work  on  how  to  organize  the  model. 
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6.1^  Formalization 


Formalization  is  of  paramount  importance  when  new  language  features  are 
introduced.  A  formal  definition  is  given  for  RML  in  terms  of  a  translation  from  RML  into  a 
standard  FOL  in  which  time  plays  an  important  role.  The  formalization  also  highlights  the 
uniformity  of  the  language  framework.  Logics  with  time  have  become  very  important  lately 
for  formalizing  specification  and  programming  languages,  especially  temporal  (modal)  logics. 
We  stick  to  a  standard  logic,  because  our  main  purpose  in  formalizing  RML  is  to  precisely 
define  and  clarify  its  features  and  to  allow  comparison  to  features  of  other  semantic  models, 
and  logic  with  its  standard  semantics  is  still  the  most  universally  understood. 

Our  approach  is  to  consider  an  RML  model  as  being  equivalent  to  a  theory  expressed 
as  a  set  of  axioms  in  a  FOL:  we  defined  a  target  language  L  and  gave  a  formal  translation 
from  RML  to  L. 

As  a  result  of  this  approach,  we  get: 

a.  A  formal  notion  of  semantics:  the  standard  semantics  of  FOL. 

b.  A  formal  meaning  of  consistency  of  an  RML  specification:  logical  consistency  of  the 

FOL  theory. 

Bubenko[81]  has  also  discussed  the  idea  of  treating  a  conceptual  model  as  a  theory. 

Our  approach  to  formalization  is  similar  to  that  of  [Rich79],  in  which  a  language  for 
program  specification  is  defined  by  q}ecifying  what  axioms  are  generated  in  a  "situational 
calculus”.  While  RML  and  the  Rich’s  calculus  have  very  different  features  as  well  as  different 
purposes.  Rich’s  formalization  was  instructive.  Our  target  language  makes  (informal)  use  of 
"sorts”,  which  simplifies  the  presentation.  Also,  we  treat  properties  as  objects  in  L,  so  that 
basic  rules  of  the  language,  such  as  the  property  induction  constraint,  can  be  stated  once  and 
for  all,  whereas  Rich  must  write  a  corresponding  axiom  for  each  function  symbol  introduced. 
On  the  other  hand.  Rich’s  underlying  logic  is  richer  than  L,  in  important  ways  that  should  be 
taken  into  account  in  future  work.  (See  the  discussion  below.) 

For  requirements  languages,  the  most  common  type  of  precise  definition  has  been  by 
relating  the  language  to  a  "graph  model  of  behavior”.  The  two  prime  examples  are  [Alford77] 
and  [WinchesterSO],  which  in  fact  both  have  their  roots  in  the  same  UCLA  graph  model.  (The 
two  requirements  languages  here  are  RSL  and  the  requirements  language  of  SARA, 
respectively,  which  are  both  really  functional  specification  languages,  not  languages  for 
requirements  modeling.)  These  models  emphasize  the  operational  semantics  of  processes,  the 
main  advantage  being  (a)  they  are  amenable  to  analysis  for  formal  properties  such  as 
deadlock;  (b)  it  is  relatively  easy  to  produce  a  simulation. 
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(.U  Meihodologj 

Finally,  the  relationship  between  SADT  and  RML  is  investigated.  Although  we  have 
established  the  importance  of  semantic  modeling  in  requirements  definition,  and  we  have 
developed  a  modeling  language  that  is  concise  and  coherent,  we  still  believe  that  requirements 
modeling  would  be  difficult  in  practice  if  it  is  not  first  decided  WHAT  is  to  be  modeled 
before  it  is  decided  HOW  to  encode  its  semantics  in  RML.  SADT  thus  serves  as  the  first  step, 
in  which  the  relevant  concepts  are  named  and  organized,  and  it  provides  a  'roadmap'  to  guide 
the  RML  modeler.  From  an  SADT  model,  it  is  relatively  straightforward  to  get  an  RML 
model. 


We  have  drawn  a  connection  between  SADT  and  RML,  with  two  main  results; 

1.  The  semantics  of  an  SADT  description  can  be  given  using  RML,  thus  bridging  the  gap 
between  an  initial  requirements  model  in  SADT  and  a  design  model. 

2.  The  SADT  description  can  guide  the  RML  modeling  effort,  and  the  derivation  of  the 
RML  model  from  the  SADT  model  is  relatively  straightforward. 

This  methodology  is  made  possible  by  certain  properties  of  SADT  that  make  it 
suitable  to  the  task:  (a)  By  focussing  on  the  selection  and  organization  of  relevant  terminology 
in  the  domain  of  discourse,  it  is  an  effective  medium  for  initial  model,  as  proved  in  practice, 
(b)  It  is  usefully  open  to  interpretation. 

In  turn,  RML  suits  the  task  because:  (a)  The  introduced  <erms  can  be  defined  to  any 
desired  level  of  detail  (b)  It  is  compatible  with  SADT;  namely,  RML’s  entity  and  activity 
objects  match  up  with  SADT’s,  and  RML  assertions  provide  additional  definitional  machinery. 

This  work  opens  the  way  to  several  avenues  of  future  work,  which  are  discussed  in  a 
section  below. 

Extending  the  Taxis  Project 

RML  extends  the  tools  provided  by  the  Taxis  Project  for  information  system  design  to 
requirements  definition.  This  f.s  a  necessary  step  in  working  toward  a  unified  Software 
Engineering  methodology  [Green^an83].  The  total  methodology  for  information  system 
development  using  Taxis  now  can  be  viewed  as  consisting  of  four  steps: 

1.  structural  modeling  using  SADT 

2.  semantic  modeling  using  RML 

3.  system  design  using  Taxis 

4.  translation  of  Taxis  program 
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Fotarc  Work 


We  divide  the  discussion  of  future  work  into  several  areas. 

6 J.l  Language  Extensions  and  Refinements 

We  want  the  ability  to  define  property  categories  within  RML.  This  would  allow  the 
language  to  be  extended  at  will.  If  property  categories  are  treated  as  classes  of  properties, 
then  an  important  aid  to  keeping  RML  consistent  in  the  face  of  change  would  be  to  organize 
them  on  an  ISA  hierarchy.  That  is  to  say,  the  same  techniques  used  to  organize  concepts  in 
the  domain  of  discourse  should  also  be  used  to  organize  the  language  features.  A  consistent 
language  is  a  prerequisite  to  a  consistent  model,  and  such  a  view  of  an  evolving,  consistent 
language  would  be  an  invaluable  tool. 

It  has  become  apparent  that  the  property  induction  principle  of  Taxis  u  not  perfectly 
suited  to  conceptual  modeling  in  RML.  It  is  based  on  the  idea  that  a  property  value  is  non* 
null  only  in  a  state  where  the  subject  is  non-null.  The  principle  needs  to  be  weakened  so  that 
one  can  represent  such  things  as  "the  input  of  activity  A'  even  at  a  time  before  or  after  A 
occurs. 


Also,  the  notion  of  property  could  be  expanded  to  complex  properties  (i^.,  properties 
with  more  than  one  subject)  as  in  Taxis.  Further,  the  meaning  of  property  could  be  usefully 
expanded  to  include  any  expressions  formed  using  functional  composition  on  complex 
properties.  Properties,  as  expressions  of  this  kind,  should  then  be  such  that  two  are  "equal*  if 
and  only  if  they  name  the  same  object  at  all  times.  The  result  of  this  is  not  only  a  more 
general  semantic  framework,  but  also,  combined  with  the  proposal  in  the  previous  paragraph, 
RML  would  match  even  more  closely  with  SADT. 

RML  should  be  extended  to  have  the  ability  to  describe  overlapping  viewpoints  and  to 
relate  the  two  viewpoints  to  one  another.  We  discuss  this  further  under  Formal  Foundations, 
below. 


We  need  to  better  integrate  time  intervals  into  the  framework.  Although  there  are 
some  abbreviations,  where  one  can  omit  time  expressions  and  get  the  intended  effect,  one 
must  still  resort  all  too  often  to  the  underlying  time  points.  It  should  be  possible  to  refer 
almost  exclusively  to  time  "objects"  (e.g.  intervals)  rather  than  to  the  time  "points"  in  the 
underlying  framework. 

J  Formal  Foondatlons 

An  important  problem  is  that  of  consistency  of  an  RML  specification.  Due  to  the 
formal  definition,  it  is  known  what  it  means  to  have  a  consistent  model.  Therefore,  one  can 
employ  theorem  provers  to  determine  the  consistency  of  a  model.  For  the  FOL  foundations, 
this  is  undecidable.  However,  it  is  suspected  that  it  is  the  case  that,  if  one  ignores  the  axioms 
that  arise  out  of  RML  assertion  e]q>ressions,  the  formulas  come  from  a  restricted,  decidable 
subset  of  FOL.  If  this  is  the  case,  then  an  RML  model  could  be  proved  consistent  down  to  the 
level  of  assertion  expressions,  which  would  then  pose  only  restricted,  small  theorems  to  prove. 
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In  spite  of  the  above  possibility,  it  would  be  more  practical  to  develop  a  set  of 
consistency  rules  that  correspond  to  intuitive  notions  of  consistency  and  use  the  FOL 
formalism  only  to  investigate  and  analyze  these  rules.  The  rules  could  be  stated  in  RML 
itself,  if  RML  is  extended,  as  described  above,  to  handle  information  such  as  the  definition  of 
property  categories. 

A  formal  analysis  is  needed  to  underly  RML  facilities  for  viewpoints.  The  approach 
of  Rich  is  instructive.  In  his  formalism,  there  are  two  basic  kinds  of  formal  objects,  "names' 
and  'situations',  and  the  notion  of  a  "behavior  function'  that  maps  name/situation  pairs  to 
abstract  (mathematical)  entities.  A  behavior  function  represents  how  some  name  behaves  (e.g. 
as  a  stack)  by  saying  for  each  situation  which  entity  the  name  refers  to.  Now,  one  expresses 
how  two  viewpoints  interrelate  by  declaring  synonyms,  ije.  names  that  refer  to  the  same 
entities  in  all  situations.  One  can  also  express  the  relationship  between  two  behaviors  that  one 
(e.g.  a  set)  is  implemented  (or  "represented")  in  terms  of  another  (e.g.  a  sequence)  by  defining 
one  behavior  function  in  terms  of  another.  This  formalism  seems  to  be  the  kind  of  thing  that 
is  needed  for  RML. 

We  have  not  dealt  with  the  question  of  formally  defining  the  SADT  language.  It 
would  be  advantageous  to  have  a  common  formalism  for  both  SADT  and  RML.  Roughly, 
SADT  establishes  partial  orders  in  both  time  (situations,  states)  and  for  objects  (attributes, 
properties),  and  these  apply  uniformly  to  both  data  and  activities;  in  addition,  these  notions 
interact  with  the  basic  idea  of  decomposition  of  a  whole  into  parts  (e.g.  the  state  of  a  part  is 
'during*  the  state  of  the  whole).  Now,  the  information  conveyed  by  an  RML  model  also 
includes,  but  goes  beyond  these  partial  orderings,  and  must  not  contradict  the  previously 
q>ecified  information. 

Consistency  rules  should  also  be  worked  out  so  that,  for  example,  two  objects  in  the 
RML  model  can  be  consistently  related  only  if  their  corresponding  SADT  boxes  are  likewise 
consistently  related  with  respect  to  the  (weaker)  SADT  connectivity  rules. 

6^3  Importing  Knowledge  Representation  Problemi  and  Solotions 

The  work  reported  in  this  thesis  aims  to  establish  a  bridge  from  Software 
Engineering  across  the  border  to  Artificial  Intelligence,  with  the  idea  of  opening  the  door  to 
future  importing  of  ideas  and  technology.  Here  are  a  few  examples  of  representation 
problems  that  are  dealt  with  in  Artificial  Intelligence  but  not  in  Software  Engineering. 

To  illustrate  the  difficult  issues  that  we  believe  must  eventually  be  addressed  in 
Software  Engineering  and  are  currently  being  addressed  in  knowledge  representation  research 
in  AI,  let  us  consider  only  a  few  of  the  representation  problems  dealt  with  in  AI  research.  [1] 

EzcepUoos  and  defanlts.  There  are  no  rules  without  exceptions.  The  procedures,  rules  and 
regulations  represented  in  a  q>ecification  are  bound  to  be  contradicted  by  the  events  they  are 
intended  to  predict.  The  systems  that  are  based  on  a  given  specification  must  have  the 
flexibility  to  allow  exceptions  to  specified  constraints.  While  some  attention  has  been  paid  to 
exceptions  from  a  Programming  Languages  point  of  view,  e.g.  [Goodenough77],  and  also  from 
within  AI  [Minsky7S],  exceptions  remain  a  largely  unexplored  research  question,  despite  their 
importance.  [Borgida84]  presents  further  discussion  on  this  issue. 

Uncertainty  and  Incompleteness.  It  is  rarely  the  case  that  a  person,  or  system,  has  complete 


[1]  An  overview  of  KR  can  be  found  in  [MyIopoulos83]. 
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knowledge  of  a  slice  of  reality  in  which  he/she/it  has  an  interest.  For  example,  it  may  be  fair 
to  assume  that  all  patients  (for  a  given  hospital)  are  known,  but  that  is  not  a  fair  assumption 
for  doctors  (who  may  or  may  not  be  affiliated  with  the  hospital).  We  may  want  to  represent 
explicitly  in  a  model  what  is  completely  known  (the  hospital  patients)  and  what  isn’t  (the 
doctors).  The  Closed  World  Assumption  [Reiter83]  for  a  given  class,  states  that  all  instances  of 
the  concept  it  represents  are  known.  This  assumption  is  only  the  tip  of  the  iceberg  as  far  as 
incompleteness  is  concerned.  We  may  want  to  represent  knowledge  such  as: 

"there  are  at  least  two  unknown  doctors',  or 

'patients  with  unknown  hospital  insurance  numbers  will  be  admitted  but  must  present 

their  number  within  a  day;  patients  without  such  numbers  will  not  be  admitted' 
[LevesqueSl]  addresses  such  knowledge  incompleteness  issues  from  a  formal  point  of  view.  To 
deal  with  incompleteness,  RML  needs  to  have  facilities  for  stating  facts  about  the  relationship 
between  the  model  and  the  world. 

Accuracy  reqatrcments  There  are  other  important  applications  of  facilities  for  relating  the 
model  to  the  world.  Specification  of  the  required  accuracy  of  information  is  also  needed,  e.g. 
to  say  'the  age  of  a  person,  as  recorded  in  the  system,  is  within  one  year  of  the  real  age  of  the 
person  involved'  or  'some  students  enrolled  in  Computer  Science  101  are  not  recorded  in  the 
system'.  Such  statements  are  examples  of  requirements  that  state  exactly  what  is  expected  of 
some  system  but  are  not  absolute.  There  is  room  for  confusion  here:  we  must  be  clear 
whether  we  are  talking  about  the  relationship  between  the  requirements  model  and  the  world 
(e^.  the  model  represents  the  real-world  concept  of  'age'  only  approximately)  or  whether  we 
are  talking  about  the  relationship  between  the  requirements  model  and  a  system  that  is 
supposed  to  meet  the  requirements  (e.g.  the  system  only  captures  the  age  approximately).  It  is 
due  to  this  type  of  confusion  that  this  topic  has  been  relegated  to  future  research. 

Stating  basic  modeling  aasnmptlons  Yet  another  application  of  facilities  for  relating  the  model 
to  the  world  is  the  ability  to  express  some  basic  assumptions  about  how  the  model  is  used,  i.e. 
how  it  represents  the  world.  For  example,  one  'motherhood'  property  of  models  is  that  they 
'reflect'  the  world(s)  they  model.  This  is  usually  taken  for  granted.  We  want  to  be  able  to 
say  formally  in  RML  such  things  as  There  is  a  one  to  one  correspondence  between  objects  in 
the  model  and  the  objects  in  the  world  they  are  supposed  to  represent.*  In  the  presence  of 
this  statement  as  an  axiom  of  the  system,  any  ^ecification  that  defines  more  than  one  object 
as  representing  the  same  world  concept  would  produce  a  contradiction.  One  might  also  like 
to  say  things  such  as  the  following:  'The  null  object  nothing  represents  no  object.'  'An 
assertion  object  is  in  a  certain  assertion  class  only  if  the  corresponding  fact  it  represents  about 
the  world  is  true.* 

Mnltlplc  viewpoints  It  is  well  known  that  one  of  the  major  problems  in  constructing  a 
specification  is  the  multiplicity  of  viewpoints  that  need  to  be  accounted  for.  For  a  hospital 
setting,  the  software  engineer  who  is  trying  to  find  out  how  are  things  done  at  the  hospital, 
before  building  a  specification,  may  get  very  different  accounts  on  how  is  a  patient  admitted 
to  the  hospital  depending  on  whether  he  talks  to  the  nurse  who  does  the  admissions  or  his 
supervisor.  Sometimes  the  differences  can  be  resolved  before  a  ^ecification  is  built.  Other 
times,  however,  contradictions  between  different  viewpoints  are  fundamental  and  should  be 
part  of  the  specification.  This  introduces  yet  another  demand  on  the  representation  languages 
use.  It  should  allow  for  the  possibility  that  a  specification  is  a  collection  of  viewpoints,  each 
of  which  is  a  specification  in  its  own  right.  It  should  also  facilitate  the  description  of 
relationships  between  the  components  of  these  viewpoints. 
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In  summary.  Software  Engineering  must  address  the  problem  of  how  to  capture 
knowledge  about  the  world  in  a  form  usable  to  both  persons  and  machines.  [1]  Moreover,  if 
the  area  of  Software  Engineering  intends  to  deal  with  the  construction  of  systems  that  exhibit 
such  attributes  as  'flexibility*,  'friendliness',  or  'intelligence',  richer  represcntation/modeling 
schemes  will  be  needed. 

One  should  not  conclude  from  this  discussion,  however,  that  the  'knowledge 
representation  problem'  has  been  solved  and  all  that  is  left  is  for  software  engineers  to  apply 
the  solutions  to  new  situations.  Although  there  has  been  progress,  much  remains  to  be  done  in 
areas  such  as  knowledge  organization,  knowledge  acquisition,  and  the  representation  of 
semantic  notions  such  as  time  and  causality,  action,  and  intention.  More  importantly  perhaps, 
these  notions  have  to  be  integrated  into  a  formal  language  that  is  suitable  for  the  construction 
of  large  knowledge  bases. 

Good  discussions  about  cross-fertilization  of  modeling  issues  are  provided  by 
[PingreeSO]  and  [Brodie83],  touching  on  such  issues  as  types,  behavior,  notations  consistency  in 
a  model,  consistency  between  models,  and  so  on.  The  importance  of  these  issues  for 
requirements  in  Software  Engineering  was  brought  up  by  [BorgidaSO]. 

6  J.4  Toward  A  Unified  Software  Engineering  Methodology 

A  unified  Software  Engineering  methodology  would  be  one  that  offers  tools  for  all 
relevant  activities  from  requirements  definition  through  construction  and  throughout  the 
lifetime  of  the  software  produced.  In  such  a  progression,  RML  fits  between  languages  like 
SADT,  which  are  used  for  initially  naming  and  organizing  concepts,  and  languages  for 
describing  (at  a  high  level)  an  information  system,  exemplified  here  by  Taxis.  One  way  to 
study  the  problems  and  issues  involved  in  engineering  software  is  to  examine  ways  to  get  from 
descriptions  in  one  language  to  descriptions  in  another,  namely  from  SADT  to  RML  to  Taxis. 
Such  a  study  would  involve,  in  essence,  an  analysis  of  what  design  decisions  are  required  to  get 
from  one  level  of  description  to  the  next.  We  have  addressed  some  of  the  problems  in 
moving  from  an  SADT  description  to  an  RML  description  but  have  not  addressed  how  to 
move  between  RML  and  Taxis.  We  are,  however,  now  in  a  position  to  investigate  what  is 
necessary  to  get  from  an  RML  model  to  a  Taxis  program,  as  further  discussed  in 
[Greenspan82b]. 

There  is  no  claim  that  these  are  the  'right*  three  languages  or  that  'three'  is  the 
proper  number  of  levels  of  language,  only  that  these  languages  are  representative  of  three 
important  levels  that  address  three  audiences  during  requirements  and  design.  [2]  Some 
researchers  adopt  the  point  of  view  that  there  ought  to  be  just  one  language  for  all  stages  of 
programming.  There  is  certainly  no  such  language  available  at  present,  and  we  do  not  take  a 
stand  on  the  issue  of  whether  or  not  it  is  possible  to  develop  such  a  language.  Indeed,  it  is 
possible  to  consider  all  of  the  levels  of  language  as  comprising  a  single  language,  only  some  of 
whose  features  are  available  to  users  at  each  level.  Thus,  while  we  talk  of  a  family  of 
languages  in  our  approach,  all  of  the  languages  are  'within  the  same  framework*.  The 


[1]  As  a  special  case  of  particular  importance  to  Software  Engineering,  consider  the 
construction  of  software  tools  such  as  for  computer-aided  programming,  maintenance,  etc.; 
these  systems  need  knowledge  bases  about  programming  concepts  and  methods.  Important 
work  in  this  area  is  [RichSl]  and  [Green??]. 

[2]  Some  advantages  of  our  choice  are  that  SADT  is  widely  and  successfully  used  and  that 
Taxis  compiles  into  executable  code  [Nixon83,  Chung83]. 
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approach  taken  is  to  use  the  same  orgamzational  (or  "epistemological")  primitives  (classes, 
properties,  and  ISA>hierarchies)  at  all  levels  while  using  different  conceptual  constructs  (the 
object  and  property  categories),  whatever  ones  are  appropriate,  at  each  level.  Whether  or  not 
one  considers  the  result  to  be  a  single  language,  we  invision  a  single  system  for  Software 
Engineering  in  which  all  of  the  necessary  linguistic  tools  exist  within  the  same  framework,  so 
that  important  problems  such  as  the  consistency  between  different  levels  of  description  can  be 
addressed. 

A  few  remarks  are  in  order  about  the  RML-Taxis  connection.  The  problem  here  is 
how  one  should  proceed  to  get  a  Taxis  description  of  an  information  system  when  given  an 
RML  model.  When  constructing  an  RML  model  one  is  concerned  with  what  concepts/objects 
there  are  in  the  world  and  how  they  are  interrelated.  The  RML  model  is  used  to  determine 
what  aspects  of  that  world  should  be  included  in  an  information  system.  Taxis  provides 
facilities  for  describing  the  semantic  database  [MylopoulosSO],  interaction  between  the  system 
and  the  user  [Barron80,82],  and  languages  for  communicating  with  the  system  [Pilote83a,b]. 
Therefore,  the  design  decisions  involved  in  getting  a  Taxis  information  system  description 
include  deciding  what  objects  represented  in  the  RML  model  should  have  information  about 
them  represented  in  the  Taxis  description.  Some  RML  entities  might  have  information  stored 
in  the  system  and  some  not.  Activities  might  be  carried  out  in  the  system  by  a  combination  of 
transactions,  or  might  be  represented  as  scripts.  Some  RML  assertions  may  be  considered  as 
constraints  that  must  be  checked  by  executing  Taxis  expressions. 

It  is  important  to  understand  the  distinction  between  the  world  model  and  the  Taxis- 
specified  information  system  (which  itself  can  be  viewed  as  a  model  of  the  world,  but  in  a  less 
direct  sense).  In  modeling  the  world  we  might  find  that  a  certain  property  is  "necessary",  e.g. 
every  physical  object  has  a  "location"  in  the  world;  but  this  information  may  be  "optional" 
from  the  point  of  view  of  the  information  system,  i.e.  we  may  not  keep  information  about  the 
location  of  all  physical  objects  represented  in  the  system.  Similarly,  in  the  world  the  fact  that 
an  employee  might  or  might  not  have  supervisor  is  usually  taken  to  mean  something  quite 
different,  namely  that  the  data  representing  the  employee’s  supervisor  may  or  may  not  be 
present.  We  note  that  the  connection  between  the  Taxis  description  and  the  RML  model 
should  be  documented  to  capture  how  the  information  about  the  world,  as  represented  in 
RML,  gets  designed  into  the  Taxis  system  description. 

6J.5  Implementatloii 

There  are  currently  plans  to  implement  RML  tools.  These  should  include: 

a.  Consistency  checker  and  database  facility  for  storing/retrieving  RML  models. 

b.  Interface  for  entering  object  definitions.  One  should  investigate  whether  a  graphical 

notation  for  RML  can  be  devised  that  can  be  overlaid  onto  SADT  diagrams. 

c.  Computer-aided  support  for  design  of  Taxis  programs  from  RML  models. 
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UbrmriM  of  Objects 

A  body  of  knowledge  described  in  RML  would  be  used  for  the  development  of  more 
than  one  system  in  the  environment  it  describes.  Library  facilities  are  needed  for  storing  and 
retrieving  objects  and  their  properties.  Wegner[82]  discusses  treating  knowledge  in  the  form 
of  'objects'  as  an  important  capital  asset. 
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APPENDIX  A 

System  Requirements  ~  State-of-the-Art 


Some  of  the  most  significant  work  on  requirements  to  date  was  reported  in  [TSE77]. 
These  papers  served  both  to  raise  the  profile  of  the  critical  nature  of  requirements  problems, 
and  to  describe  some  large-scale  requirements  technology  efforts. 


PSL/PSA 

PSL/PSA  (Problem  Statement  Language/Analyzer)  was  developed  as  part  of  the 
ISDOS  Project  [Teichroew77].  It  was  the  first  automated  facility  for  storing  and  retrieving 
functional  specifications,  and  it  is  widely  used  today.  The  language,  PSL,  provides  several 
object  types,  such  as  INPUT,  PROCESS,  OUTPUT,  SET,  ENTITY,  INTERFACE,  etc.,  which 
together  with  several  relationship  types  allow  statements  such  as 

INTERFACE  payroU-dcpt  GENERATES  INPUT  work-data 
PROCESS  compute-pay  USES  work-data 


The  analyzer,  PSA,  checks  for  certain  kinds  of  inconsistencies,  such  as  invalid  combinations  of 
object/relationship  types  or  the  omission  of  mandatory  relationships,  and  allows  various 
reports  to  be  extracted. 

The  'semantics'  of  PSL  are  defined  by  its  analyzer^  i.e.  a  specification  is  considered 
consistent  if  no  error  messages  are  produced  when  subjected  to  PSA.  A  description  of  what 
comprises  a  valid  specification  is  given  is  lists  of  rules  in  the  PSL  manual  [Teichroew75]. 

PSL  object  types  for  describing  EVENTS,  CONDITIONS,  and  some  other  objects  arc 
given  only  by  natural  language  'comment  entries'  in  lieu  of  further  definition,  so  the 
associated  consistency  rules  can  require  only  that  the  entries  not  be  omitted. 

An  interesting  extension  to  PSL  is  proposed  by  [Agusa-6ICSE,p20],  in  which  the 
ability  to  define  arbitrary  binary  predicates  to  express  further  semantic  information,  has  been 
added  to  the  language,  thus  enabling  some  deeper  forms  of  semantic  consistency  checking. 

RSL  (Requirements  Statement  Language)  is  the  system  requirements  language 
developed  as  part  of  the  System  Requirements  Engineering  Methodology  (SREM)  [Bell77],  a 
comprehensive  and  large-scale  effort  to  study  requirements  problems  and  devise  tools  and  a 
methodology.  RSL  is  a  language  providing  object  ('element')  and  relationship  types  as  in  PSL. 
RSL  was  indeed  influenced  by  PSL  but  has  significant  extensions  geared  to  the  specification  of 
real-time  systems.  One  important  extension,  R-NETS,  is  used  to  give  graphical  specifications 
of  control  structures. 


-91- 


The  automated  facility  for  RSL  specifications  is  called  REVS  (Requirements 
Engineering  and  Validation  System)  (RSL77].  REVS  has  a  database  for  storing  specifications, 
multi-colored  graphics  interface  for  drawing  R-NETS,  and  an  'analyzer*  for  checking  the 
consistency  of  specifications.  Due  to  R-NETS,  there  is  enough  information  in  an  RSL 
specification  to  automatically  generate  a  (Pascal)  simulation  program  from  the  requirements 
database;  certain  nodes  on  the  R-NET,  called  VALEDATION-POINTS,  indicate  data  is  to  be 
collected  to  validate  the  simulation. 

RSL  itself  has  a  couple  of  noteworthy  features.  RSL  has  an  object  called  a 
HIERARCHY,  with  which  one  describes  valid  structures  forced  from  RSL  relationships.  An 
example  is  the  following: 


I  kjcloDES 


The  nodes  are  labeled  by  RSL  element  types  and  the  arcs  are  labeled  with  RSL  relationship 
types.  In  linear  form,  we  have; 

HIERARCHY  INFO-SOURCE  =  INPUT-INTEPJACE; 

INPUT-INTERFACE  PASSES  MESSAGES; 

MESSAGE  MADE  BY  FILE; 

MESSAGE  MADE  BY  DATA; 

FILE  CONTAINS  DATA; 

DATA  INCLUDES  DATA. 


The  hierarchy  acts  as  a  'template'  or  'schema'  for  the  structure  of  elements  of  type  INPUT- 
INTERFACE.  The  hierarchies  explicitly  specify  some  of  the  'semantics'  of  the  language  that 
would  be  otherwise  hidden  in  the  'analyzer*.  The  user  can  sec  more  clearly  what  i.s  a  correct 
specification. 
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Another  interesting  feature  of  RSL  is  that  inconsistencies  can  be  found  by  detecting 
nonempty  sets  of  anomalous  elements.  Such  sets  can  be  defined  by  the  user.  For  example  to 
require  that  for  every  MESSAGE  element  in  the  database  there  must  exist  an  INTERFACE 
element  that  PASSES  it,  one  can  specify: 

SET  MESSAGE-NOT-PASSED  = 

MESSAGE  THAT  IS  NOT  PASSED 


The  elements  showing  up  in  this  set  are  MESSAGES  that  no  INTERFACE  PASSES,  and  the 
retrieval  of  these  elements  should  produce  an  empty  set. 

Lastly,  we  mention  that  RSL  is  extensible,  ix.  the  definition  of  element  types  can  be 
changed,  and  new  element  and  relationship  types  can  be  added  and  deleted,  with  the  analyzer 
continuing  to  do  its  job  in  many  cases. 


SADT 


SADT  is  of  a  very  different  ilk  than  PSL  and  RSL.  Although  it  is  usually  discussed 
with  respect  to  functional  specifications  [Ross77a],  it  can  be  used  (in  the  italicized  words  of 
[Ross77b])  "to  bind  up,  structure,  and  communicate  units  of  thought  expressed  in  any  other  chosen 
language" 

Since  the  graphical  language  of  SADT  is  used  in  conjunction  with  RML  in  the  thesis, 
the  reader  is  referred  to  Chapter  S  for  a  detailed  discussion. 
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APPENDIX  B 

Summary  of  RML  Syntax  and  Semantics 

B.l  SynUx 

A  concise  summary  of  RML  syntax  is  given  below  using  a  slightly  modified  BNF 
notation. 

Meta-symbols  (unless  quoted):  <  >  n=  {  )  (  J  I 

Symbols  in  boldface,  italics,  and  all-caps  are  terminals 

Symbols  consisting  of  a  string  in  angle  brackets  (i.e.  <  ,>  )  are  nonterminals 

[<  symbol>  ]  signifies  zero  or  one  occurrences  of  <  symbol> 

(i.e.  <  symbol>  is  'optional*) 

{<  symbol> }  signifies  zero  or  more  occurrences  of  <  8ymbol> 

{<  symbol> }+  signifies  one  or  more  occurrences  of  <  symbol> 


(1)  Requirements  model 

<reqs-model>  ::=  {<  object-definition>  )+ 


(2)  Object  definition 

<  object-definition>  n=<8ubject>  ({<  factual-properties>  }) 
in  {<classifier>}+ 
isa  {<5uperclas8>)  + 
with  {<  definitional-properties>  } 
<subject>  ::=  <user-defined-object> 

<classifier>  <object> 

<superclass>  ::=  <object> 
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(3)  Factual  properties 

<  factual-propertie8>  ::=  <  fact>  {,  <  fact>  ) 

<  fact>  <  attribute>  :  <  attr-expr> 

<attr-e3ipr>  ::=<  object >  l<attribute>  I  <  built-in-tenn> 
I  <  attr-c3q)r>  @  <  attributo 
<attributc>  ::=  <  U8cr-defincd-attr>  \  self  \  now 
For  <  built-in-term > ,  see  assertions,  below. 


(4)  Definitional  properties 

<  definitional-properties>  ::= 

<  property-category>  {<  definitional-property>  ) 

<  definitional-property>  ::=  <  attribute>  :  <  property-value> 

<  property- value >  ::=<  object  >  [(<  bindings>  )] 

<  bindinp>  ::=  <  fact>  {,  <  fact>  ) 


(S)  Property  categories 

<  property-category>  ::= 

<  entity-pcat>  I  <  activity-pcat>  I  <  assertion-pcat> 
<entity-pcat>  put  I  association  I  necessary 

I  Invariant  I  Inltcondl  flnalcond  I  producer 
I  consumer  I  modlfler  I  constraint 

<  activity-pcat>  Input  I  controll  output  I  precond 

I  postcond  I  actcond  I  itopcond  I  part  I  constraint 

<  assertion-pcat>  ::=  argument  I  part  I  constraint 


(6)  Objects 

<  objcct>  ::=  <  uscr-defined-objcct>  I  <  built-in-object > 

I  <  constructcd-object> 

<  built-in-object >  OBJECT  I  TOKEN  I  CLASS  I  METACLASS 

I  ENTITY  I  ACTIVITY  I  ASSERTION  I  nothing 
I  ENTITY_CLASS  I  ACTIVITY  CLASS  I  ASSERTION_CLASS 
I  ENTITY_METACLASS  I  ACTIVITY_METACLASS  I  ASSERTION_METACLASS 
<constructed-object>  ::=  class  -of  <  user-defined-object> 

<  user-defined-object>  ::=  <  identifier>  I  <  assertion> 
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(7)  Assertions 

<as5crtion>  n=  <prcdicatc>  (<  bmding8>  ) 

\foraIt  <var>  In  <objcct>  <asscrtion> 

{exists  <var>  in  <  object  >  [suchthat  I  h'/zA]  <  assert  ion  > 

I  (  <  asBertion>  )!'{'<  a88ertion>  *)'  I '['  <  a8sertioa> 

I  not  <  assertion  > 

l<as5ertion>  <conncctivc>  <as8ertion> 

<connective>  v.-  and  I  or  I  implies  I  if  f 

<  predicate>  :;=  <  u8er-dcfined-objcct>  I  <  built-in-pred> 

<built-in-prcd>  ::=  IN  I  ISA  I  =  I  #  I  DURING  I  NEXT  I  BEFORE  I  SAMEBEGIN 

<  built-in-tcrm>  ::=  RANGE(<  bindingB>  )  I  PVAL(<  bindings>  ) 

I  START(<  binding8>  )  I  END(<  binding8>  ) 


(8)  User-defined  objects 

User  defined  symbols  are  identifiers  introduced  by  the  user: 

<  user-defined-attr>  ::=  <  lower-case-identifier> 

<  user-defined-object>  <  upper-case-identifier> 


B  J  ScmnnUcs 

(1)  Requirements  model 

(2)  Object  definition 

<  subject> ,  <  classifier> ,  and  <  superclass>  are  of  same  category 

If  classification  level  of  <subject>  is  i=0,l>2  (for  token,  class,  metaclass) 
then  classification  level  of  <classifier>  is  i+1. 

(The  only  symbols  of  level  3  are  METACLASS,  ENTrrY_METACLASS, 
ACTIVITY_METACLASS,  and  ASSERTION_METACLASS.) 

A  <superclass>  is  of  the  same  classification  level  as  the  <8ubject> 

The  property  induction  principle  holds  between  <8ubject>  and  <clas8ifier> 

The  ISA  constraints  hold  between  <superclass>  and  <subject>. 

There  are  a  few  rules  for  use  of  identifiers,  e^.  peats  are  reserved  (if  the 
parsing  is  to  be  done  without  the  aid  of,  say,  filling  in  a  template  where  it 
is  obvious  that  the  identifiers  are  attrs  or  objects  or  peats,  etc. 

Also,  properties  of  same  name  in  separate  categories  are  really  the  same  property. 
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(3)  Factual  properties 

The  facts  are  properly  induced. 

(4)  Definitional  properties 

(5)  Property  categories 

If  the  property  category  is  ...  then  the  category  of  the  pval  is  ... 

Each  peat  is  defined  by  an  assertion. 

(6)  Objects 

Each  of  the  built-in  objects  fits  somewhere 

(7)  Assertions 

The  semantics  of  an  assertion  are  the  semantics  of  its  translation.  Left  to  right  precedence. 
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APPENDIX  C 

Modeling  the  Organization  of  an  IFIP  Working  Conference 


C.l  [ntrodocUoB 

In  this  Chapter,  RML  is  used  to  model  the  organization  of  an  IFIP  working 
conference.  This  example  has  been  used  widely  by  authors  of  information  system  design 
languages  to  illustrate  the  features  of  their  languages  [011e82].  The  original  statement  of  the 
problem  is  only  about  a  page  in  length.  The  requirements  analyst  must  fill  in  much  more 
detail,  presumably  by  interacting  with  human  experts  on  the  subject  of  organizing  a  working 
conference.  In  this  regard,  we  had  the  benefit  of  the  experience  and  imagination  of  previous 
authors’  determination  of  facts  and  assumptions  about  working  conferences.  In  particular,  we 
gleaned  information  from  three  previous  examples:  [Gustaf8son82],  [Lundeberg  82],  and 
[Verheijen82].  We  will  introduce  the  details  of  an  IFIP  working  conference  as  we  introduce 
the  objects  that  comprise  the  model. 

CJl  Entitles 

A  conference  is  defined  by  the  class  CONFERENCE  as  follows: 

CONFERENCE  in  ENTITY_CLASS  isa  ENTITY  with 
parts 

conf-name:  CONFERENCE_NAME 
topic:  TOPIC 

conf-dates:  DATE-INTERVAL 
associations 

program-committee:  COMMITTEE 
organizing-committee:  COMMITTEE 
subj-areas:  class  -of  SUBJECT_AREA 
papers:  class  -of  PAPER 
pgm:  CONF_PROGRAM 
constraints 

no-dbl-service:  Forall  x 

[IN(x,pc*mbrs)  if  f  [not  IN(x,oc»mbrs)]] 
subj-areas-relevant:  [ISA(subj-area8,  topic  •subjects)] 


[1]  A  conference  has  a  fixed  name,  topic,  and  dates  of  occurrence.  Other  related  entities  are 
the  program  committee,  the  organizing  committee,  the  class  of  subject  areas  that  are  of 
relevance  to  the  conference,  and  the  conference  program;  these  are  aasoclatlons,  which  may 
change  when,  for  example,  one  of  the  committees  is  established,  the  list  of  subject  areas  is 
altered,  or  the  conference  program  is  created.  There  is  a  constraint  property  that  says  that  no 


[1]  It  will  be  assumed  that  the  same  property  name  (attribute)  can  be  used  in  non-ISA-related 
definitions  and  bear  no  relationship  to  one  another,  but  in  ISA-related  classes  they  are 
assumed  to  be  the  same  property  and  must  obey  the  ISA  constraints. 
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person  may  serve  as  a  member  of  both  the  program  and  organizing  committees.  The  definition 
of  TOPIC  would  show  a  class  of  related  subject  areas  (associated  by  property  "subjects'),  and 
the  second  constraint  on  CONFERENCE  says  that  every  subject  area  defined  as  belonging  to 
the  topic  is  one  of  the  subject  areas  of  the  conference  topic. 

Entities  that  are  related  to  a  conference  can  be  made  an  instance  of 
CONFERENCE_ENTlTY  for  the  purpose  of  relating  a  specific  conference  to  them. 

CONFERENCE.ENTTTY  in  EN’nTY_CLASS  isa  ENTITY  with 
part  conf:  CONFERENCE 


In  the  definition  of  CONFERENCE,  we  have  made  reference  to  a  few  other  classes, 
which  are  now  defined,  along  with  some  of  the  other  classes  that  come  into  play. 

COMMITTEE  in  EN’nTY_CLASS  isa  CONFERENCE.ENTTTY  with 
aaoclation 

mbrs:  class  -of  POTENTIAL  PARTICIPANT 
chpn:  POTENTIAL  PARTICIPANT 
charter:  TASK_DESCRIPTION 

constraint 

chpn-is-mbr:  IN(chpn4nbrs) 


The  program  committee  and  organizing  committee  are  subclasses  of  COMMITTEE  and 
therefore  inherit  its  properties,  namely,  a  class  of  committee  members,  a  chairperson,  and  a 
charter.  The  two  specializations  of  COMMITTEE  have  specialized  charter  properties,  i.e. 
PROGRAM_PLANNING_TASK_DESCRIPTION  and 

EVENT_PLANNING_TASK_DESCRIPTION  are  subclasses  of  TASK_DESCRIPTION.  Also, 
since  COMMITTEE  is  a  subclass  of  CONFERENCE_ENTITY,  each  committee  has  a  property 
(conf)  saying  for  what  conference  it  is  the  committee. 

We  will  not  bother  to  define  the  other  classes  mentioned  above.  In  some  cases  (e.g. 
CONFERENCE_NAME),  we  might  consider  the  class  to  be  "primitive”,  in  the  sense  that  we 
do  not  have  any  interesting  properties  in  mind  to  specify.  In  other  cases,  the  reader  might 
think  of  additional  properties  that  could  be  added  to  our  example;  this  is  fine  as  long  as  no 
inconsistencies  are  introduced.  In  other  words,  a  specification  is  not  inconsistent  just  because 
it  is  incomplete:  further  properties  can  be  added  to  make  it  more  complete  as  long  as  no 
inconsistencies  are  introduced.  [1] 

An  IFIP  working  group  conference  is  a  conference  that  has  been  planned  by  an  IFIP 
working  group. 

IFIP_WG_CONFERENCE  in  EN’nTY_CLASS  isa  CONFERENCE  with 
part  organ  izing-wg:  IFIP_WORKING_GROUP 


[1]  We  mean  consistency  here  in  the  sense  that  the  FOL  theory  into  which  it  translates  is 
logically  consistent. 
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There  are  ■  handful  of  entity  classes  that  are  central  to  the  example,  each  having 
several  subclasses  of  interest.  First,  there  are  persons,  who  play  several  roles  in  the 
organization  of  a  working  conference.  Second,  there  are  various  sorts  of  communiques 
(invitations,  notifications,  etc.)  exchanged  between  organizers  and  potential  participants. 
Third,  there  are  papers  that  are  submitted,  reviewed,  accepted,  rejected,  and  so  on.  Finally, 
we  note  the  importance  of  dates,  especially  as  deadlines.  This  gives  us  four  more  classes  to 
describe: 

PERSON  -  the  class  of  all  persons 
COMMUNIQUE  -  the  class  of  all  communiques 
PAPER  *•  the  class  of  all  papers 
DATE  -  the  class  of  all  dates 


Each  of  these  classes  is  at  the  top  of  an  interesting  ISA  hierarchy  of  classes.  Let  us  take  each 
of  them  in  turn.  [1] 


The  following  diagram  shows  the  ISA  hierarchy  of  classes  of  persons 


[1]  We  have  not  said  precisely  what  these  object  classes  represent,  e.g.  whether  a  paper  in 
PAPER  is  one  that  has  been  written,  submitted,  or  could  be  just  an  imagined,  potentially 
submitted  paper.  This  information  may  be  necessary  as  part  of  the  definitions  of  these  classes, 
and  if  so,  it  must  be  explicitly  stated.  We  will  add  information  as  necessary  as  we  go. 
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The  meaning  of  each  class  is  stated  informally  below: 

PERSON  -  persons  in  the  world 

POTENTIAL_PARTICIPANT  -  persons  who  may  play  some  part  in  the  conference 

planning  or  happenings 

AUTHOR  -  persons  who  write  papers 

CONF_AUTHOR  -  authors  who  have  submitted  a  paper  to  this  conference 
POTENTIAL_REFEREE  -  a  person  who  might  be  asked  to  referee 
REFEREE  --  persons  who  have  been  asked  to  referee  a  paper 
PC-MEMBER  -  member  of  program  committees 

REFEREE_MGR  >-  a  program  committee  member  who  has  been  appointed  the  manager 
of  referees  for  some  subject  area. 

SESSION'CHMN  -  someone  appointed  as  the  chairman  of  a  conference  session 
NAT’L_REP  -  national  representatives  of  IFIP 

ORGANIZING_WG_MBR  -  a  member  of  the  organizing  working  group 
WG  KfflR  --  a  member  of  a  working  group  with  related  interests, 
whose  members  might  be  invited 

INVITED_PERSON  ~  a  person  to  whom  an  invitation  has  been  sent 
ATTENDEE  -  someone  who  has  accepted  an  invitation  to  attend  the  conference 
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We  define  the  most  general  class  of  this  hierarchy,  PERSON,  to  capture  the  most 
general  properties  of  persons,  which  arc  applicable  to  all  of  the  subclasses. 

PERSON  in  PERSON_CLASS  isa  ENTITY  with 
parts 

name:  NAME_VALUE 
asBocladon 

mailing-addr:  ADDRESS_VALUE 
business-number:  TELEPHONE  NUMBER 


We  do  not  give  any  sufficient  conditions  or  producing  activities  for  PERSON,  which  reflects 
the  fact  that  in  this  q>ecification  we  do  not  care  how  persons  come  into  existence,  but  only 
that  those  that  exist  have  the  specified  part  and  association  properties. 

We  define  POTENTIAL_PARTICIPANT  to  distinguish  general  persons  from  those 
who  take  part  in  the  conference.  A  potential  participant  has  as  parts  an  interest,  which 
according  to  the  constraint  is  one  of  the  subject  areas  of  the  conference.  [1] 

POTENTIAL_PARTICIPANT  in  PERSON_CLASS  isa  PERSON,  CONFERENCE_ENTITY  with 
parts 

interest:  SUBJECT_AREA 
constraint 

related-interest:  IN(interest,  conf  •  subj-areas) 


AUTHOR  represents  the  class  of  authors,  defined  as  persons  who  have  written  a  paper  (not 
necessarily  related  to  conferences).  This  gives  an  opportunity  to  capture  in  the  abstract  what 
an  author  is  in  a  way  that  might  be  shared  across  several  domains  of  discourse,  not  just  in  a 
way  special  to  conferences. 

AUTHOR  in  PERSON_CLASS  isa  PERSON  with 
Invariants 

ex-paper:  Exists  p  in  PAPER 

written-by-person:  WRlTES_PAPER(who:je//  ,  paper:p) 


The  assertion  represents  that  someone  writes  a  paper  any  time  in  the  past,  present,  or  future, 
.  and  thus,  an  author  is  someone  who  has  ever  written  or  will  ever  write  a  paper.  (Similarly,  we 
will  define  PAPER  as  the  class  of  all  papers,  not  just  those  for  a  conference.)  A  'conference 
author*  is  now  defined  as  a  potential  participant  who  has  submitted  a  paper  to  the  conference. 

CONF_AUTHOR  in  PERSON_CLASS  isa  AUTHOR,  POTENTIAL_PARTICIPANT  with 
Invariants 

is-submitted:  Exists  p  in  PAPER  such  that  IN(p,SUBMnTED_PAPER) 


Following  are  definitions  for  the  other  author  classes: 


[1]  Recall  that  conf  is  inherited  from  CONFERENCE_EN'nTY. 
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PRESENTOR  in  PERSON_CLASS  isa  CONF_AUTHOR  with 
coBitraliits  author-presents:  Forall  p  in  PAPER 

PRESENTS(who:  self  ,  what:  p)  implies  WRITES_PAPER(whoae//  ,  paper:p) 
invited:  INVITED(who:  self  ,  where:  conf) 
attend:  PLAN_TO_ATTEND(who:  self  ,  where:  conf) 


CORR_AUTHOR 

constraint 

(IN(x,CORR_TO_AUTHOR)  and  IN(pJPAPER)  and  xopaper=p] 
implies  xo  receiver =je// 


Various  classes  of  persons  involved  in  refereeing  are  shown  below.  A  potential 
referee  is  someone  who  can  be  chosen  as  a  referee.  A  person  becomes  a  potential  referee 
simply  by  being  added  to  the  list.  A  referee  is  someone  to  whom  a  request  for  refereeing  has 
been  sent.  (The  assumption  is  that  the  potential  referee  will  accept  the  job.)  A  referee 
manager  is  the  manager  for  one  subject  area,  and  is  also  a  potential  referee  in  that  area. 

POTENTIAL_REFEREE  in  PERSON_CLASS  isa  POTENTIAL_PARTICIPANT  with 
producer 

add-to-list:  INSERT_POTENTIAL_REFEREE 

REFEREE  in  POTENTIAL_REFEREE  with 
producer 

send-paper:  SEND_PAPER_TO_REFEREE 
REFEREE_MGR  in  PERSON_CLASS  isa  POTENTIAL_REFEREE 


Persons  to  invite  include  IFIP  national  representatives,  session  chairpersons,  members 
of  relevant  working  groups,  and  members  of  the  organizing  working  group.  A  priority  system 
is  used  to  decide  which  of  these  persons  will  actually  become  invited.  An  attendee  is  a  person 
who  is  invited  and  accepts  the  invitation  (We  might  think  of  having  a  class  for  potential 
attendees,  who  become  actual  attendees  if  they  actually  show  up  on  the  conference  dates;  for 
the  purposes  of  this  model,  which  is  used  for  describing  the  planning  of  a  conference,  we  will 
not  make  this  distinction.) 
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PERSON_TO_INVITE  in  PERSON_CLASS  isa  POTENTIAL_PARTICIPANT 

NArL_REP  in  PERSON_CLASS  isa  PERSON_TO_INVITE 

SESSION_CHMN  in  PERSON_CLASS  isa  PERSON_TO_INVITE 
•noclation  session:  SESSION 
InvarUnt  session  •chmn  =  self 

RELEVANT_WG_MBR  in  PERSON_CLASS  isa  PERSON_TO_INVITE 
ORGANIZING_WG_MBR  in  PERSON_CLASS  isa  RELEV ANT_WG_MBR 
INVITED_PERSON  in  PERSON_CLASS  isa  PERSON_TO_INVITE 
ATTENDEE  in  PERSON_CLASS  isa  INVITED_PERSON 


Now  we  move  on  to  another  collection  of  closely  related  classes,  depicting  the  various 
types  of  communiques.  COMMUNIQUE  has  the  following  interesting  subclasses:  [1] 

CONF_COMMUNIQUE  --  any  corre^ondence  sent  or  received  regarding  a  conference 
COMMUNIQUE_TO_PUBLIC  -  message  addressed  to  general  public 
CALL-FOR-PAPERS  -  notice  of  conference  and  invitation  to  submit  paper 
CONF_ANNOUNCEMENT  -  a  message  about  the  conference  issued  to  the  public 
DIRECTED_COMMUNIQUE  -  message  sent  between  two  parties 
REFEREE_CORRESPONDENCE  --  any  correspondence  to  or  from  an  actual 
or  potential  referee 

CORR_TO_REFEREE  ~  corre^ndence  sent  to  referee 
REQUEST_FOR_REFEREE-  an  invitation/request  to  referee  a  paper 
REFEREE_REMINDER  --  a  letter  to  remind  the  referee  to  reply 
CORR_FROM_REFEREE  -  correspondence  sent  by  a  referee 
AUTHOR_CORR  -  any  correspondence  to  or  from  an  author 
CORR_FROM_AUTHOR  ~  correspondence  sent  by  an  author 
CORR_TO_ AUTHOR  --  any  correspondence  to  or  from  an  author 
SUBMiTTAL_LETTER  -  notification  of  the  submitting  of  a  paper 
WITHDRAWAL  -  notification  that  a  submitted  paper  is  to  be  withdrawn 
INVITATION_REQUEST  ~  a  communique  that  requires  a  reply; 
an  invitation  or  request 

REPLY  --  an  answer  to  one  of  the  'invitation*  communiques 
REVIEW_REPLY  --  reply  from  a  person  invited  to  referee 
LETTER_OF_INTENT  —  a  reply  to  call-for-papers  stating  a  paper  will  follow 
ACK  LETTER  -  a  message  confirming  that  a  submitted  paper 
has  been  received  by  the  program  committee 

DECISION_LETTER  —  notification  of  acceptance  or  rejection  of  a  paper 
ACCEPT ANCE_LETTER  -  notification  of  acceptance  of  a  paper 
REJECTION_LETTER  -  notification  of  rejection  of  a  paper 
INVITAT10N_T0_ATTEND  --  invitation  to  attend  the  conference 


[1]  Communiques  are  messages  between  people  in  the  world.  It  is  irrelevant  whether  this  will 
be  implemented  by  messages  in  a  computer  system  or  by  mail  outside  an  information  system 
that  otherwise  keeps  track  of  the  status  of  correspondence  sent  and  received. 
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Let  us  define  just  some  of  these  classes.  First,  a  conference  communique  is  a  specialization  of 
the  class  of  communiques,  from  where  it  gets  its  sender  and  receiver  properties,  which  are 
here  specialized  to  be  potential  participants  of  the  conference.  A  communique  is  created  by 
an  instance  of  PREPARE,COMMUNIQUE  that  has  as  its  preparer  the  sender.  Send  and 
receive  activities  change  the  status  of  the  communique  to  sent,  received,  lost,  etc.  There  is  a 
constraint  that  says  communiques  are  sent  before  they  are  received. 


CONF,COMMUNIQUE  in  ENTITY,CLASS  isa  CONFERENCE,ENTITY,  COMMUNIQUE  with 

part 

sender:  POTENTIAL,PARTICIPANT 
receiver:  POTENTIAL,PARTICIPANT 
aasoclatlon 

status:  COMMUNIQUE,STATUS 
producer 

write:  PREPARE_COMMUNIQUE(comm:  self  ,  by:  sender) 

updater 

send:  SEND(comm:  self  ) 
receive:  RECEIVE(comm:  self  ) 

constraints 

send-before-receive:  end(send)  <  start(receive) 


An  invitation/request  is  a  communique  for  which  a  reply  is  expected  by  a  certain  date.  There 
is  a  property  of  REPLY  saying  what  the  reply  is  a  reply  to  and  a  constraint  saying  that  the 
sender  of  the  first  is  the  receiver  of  the  latter  and  vice  versa.  INVITATION,REQUEST  has  a 
constraint  expressing  that  a  reply  is  received  by  the  deadline  or  else  a  reminder  letter  is  sent. 
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INVITATION_REQUEST  in  EN'nTY_CLASS  isa  COMMUNIQUE  with 
part  nvp-dcadline:  DATE 

cooMralnt 

gct-rcply_or-rcmind:  {Exists  r  in  REPLY  such  that 

t^to=self  and  BEFORE(r* receive* when jrsvp-dcadlinc)) 
or  {Exists  X  in  REMINDER  with 

REPLY  in  EN'nTY_CLASS  isa  CONF_COMMUNIQUE  with 

part 

to:  INVITATION_REQUEST 
constraint 

send-back:  sender  =  to*  receiver  and 
receiver  =  to*  sender 


Referee  correspondence  consists  of  communiques  that  go  to  or  come  from  (potential,  which 
includes  actual)  referees.  Correspondence  to  referees  specifies  that  the  receiver  is  a  referee, 
while  correspondence  from  referees  specifies  that  the  sender  is  a  referee. 

REFEREE_CORRESPONDENCE  in  ENTrrY_CLASS  isa  CONF_COMMUNIQUE  with 
constraint 

one-is-ref:  IN (sender,  POTENTlAL_REFEREE) 

or  IN(receiver,  POTENTIAL_REFEREE) 

CORR_TO_REFEREE  in  ENTITY_CLASS  isa  REFEREE_CORRESPONDENCE  with 
part  receiver:  POTENTIAL_REFEREE 

CORR_FROM_REFEREE  in  EN'nTY_CLASS  isa  REFEREE_CORRESPONDENCE  with 
part  sender:  POTENTIAL_REFEREE 


There  are  similar  definitions  for  author  correspondence  which  we  will  not  include  here. 

Other  classes  of  referee  communiques  are  the  following.  Note  that  a  request  for  refereeing 

inherits  properties  from  INVITATION_REQUEST,  including  a  deadline  for  a  reply. 

REQUEST_FOR_REFEREE  isa  CORR_TO_REFEREE,  INVITATION_REQUEST  with 
part  paper:  SUBMnTED_PAPER 

REFEREE_REMINDER  isa  CORR_TO_REFEREE  with 
part  re:  REQUEST_FOR_REFEREE 

REVIEW_REPLY  isa  CORR_FROM_REFEREE  with 
part  reviewed -paper: 


Other  interesting  a^ects  of  the  model  that  involve  these  classes  are  addressed  in  the  activities 
that  describe  the  course  of  events  in  getting  papers  reviewed  and  selected. 
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The  ISA-hierarchy  for  various  sorts  of  papers  appears  below,  followed  by  a  brief 
description  of  each  class. 
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PAPER  ••  the  general  concept  of  a  paper 

CONF_PAPER  ~  papers  written  for  the  purpose  of  being  submitted  to  a  conference 
PROMISED_PAPER  -  a  paper  promised  by  a  letter  of  intent  to  be  submitted 
SUBMnTED_PAPER  ~  a  paper  received  by  the  program  committee 
PAPER_IN_REVIEW  -  a  paper  that  has  been  given  to  referees  for  review 
REFEREED_PAPER  -  a  paper  for  which  the  the  review  process  has  been  completed 
ACCEPTED_PAPER  -  a  paper  that  has  been  accepted 
REJECTED_PAPER  ~  a  paper  that  has  been  rejected 
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PAPER_CLASS  in  METACLASS  isa  ENnTY_CLASS  with 
card:  NUMBER 

PAPER_CLASS_BY_SUBJECT  in  METACLASS  isa  PAPER_CLASS  with 
part  subj:  SUBJECT_AREA 

PAPER_CLASS_BY_AUTHOR  in  METACLASS  isa  PAPER_CLASS  with 
part  auth:  AUTHOR 

PAPER  in  PAPER_CLASS  isa  ENTITY  with 
parts 

title:  TITLE 

authors:  class  —of  AUTHOR 

subject:  SUBJECT_AREA 

CONF_PAPER  in  PAPER_CLASS  isa  PAPER,  CONFERENCE_EN’nTY  with 
association  status:  PAPER_STATUS 

SUBMTTTED.PAPER  in  PAPER_CLASS  isa  CONF_PAPER  with 
producer 

submit:  SUBMIT_PAPER(^:  self  ,  to:  conf) 

Invariant 

s:  SUBMITTED(papcr:  self  ,  confxonf) 
part  date-submitted:  DATE 

PAPER_IN_REVIEW  in  PAPER_CLASS_BY_SUBJECT  isa  SUBMITTED_PAPER  with 
referees:  class  -of  REFEREE 
paper  sent  to  each  referee 
subject  of  paper  is  a  subject  area  of  referee 

REFEREED_PAPER  in  PAPER_CLASS_BY_SUBJECT  tsa  SUBMnTED_PAPER  with 
every  paper  is  an  instance  of  either  accepted  or  rejected  paper 

WITHDRAWN_PAPER  in  PAPER_CLASS  isa  SUBMnTED_PAPER 


C3  Activities 

Here  is  an  outline  of  the  activity  of  organizing  a  working  conference  in  terms  of  a 
'part-of*  hierarchy  of  activities.  [1] 


[1]  The  outline  was  taken,  but  only  roughly,  from  information  in  a  diagram  in  [Verheijen82, 
page  562]. 
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0.  Organize  a  working  conference 

1.  Initiate  a  working  conference 

1.1  Pick  program  committee  members 

12  Pick  organizing  committee  members 

13  Pick  subject  areas 

2.  Establish  the  program 

2.1  Solicit  contributions 

2.12  Send  out  call  for  papers 

2.13  Keep  track  of  replies 

22  Review  and  select  papers 

23.1  Assign  referees 
222  Get  reviews 
233  Pick  papers 

23  Design  program 

3.  Ensure  attendance 

3.1  Decide  who  to  invite 
33  Invite  them 

33  Keep  track  of  replies 


The  PC  solicits  contributions,  which  involves  putting  out  the  call  for  papers,  and 
keeping  track  of  responses.  The  PC  also  handles  the  refereeing  and  selection  of  papers  for  the 
conference,  which  involves  securing  the  service  of  appropriate  referees  and  making  selections 
based  on  their  reviews.  Finally,  the  program  must  be  designed  by  grouping  appropriate, 
selected  papers  into  sessions.  The  job  of  the  OC  is  to  make  sure  that  appropriate  persons  are 
given  a  chance  to  attend. 

First,  as  for  entities,  we  define  a  class,  CONF_ACTIVITY,  that  has  all  conference 
activities  as  instances.  All  instances  have  a  conf  property.  All  subclasses  of 
CONF_ACTIVITY  inherit  this  property. 

CONF_ACTIVITY  in  ACTIVnT_CLASS  isa  ACTIVITY  with 
control  conf:  CONFERENCE 


Let’s  now  define  the  overall  activity  of  organizing  a  working  conference. 


ORGANIZE-WORKIKG-CONFERENCE  in  ACTIVITY_CLASS  isa  CONF_ACTIVITY  with 
coo  troll 

plans:  CONFERENCE-PLANS 
papers;  class  -of  PAPER 
corr-rced:  class  -of  COMMUNIQUE 

parti 

initiate:  INmATE_WORKING_CONF 
make-pgm;  ESTABLISH_CONF_PROGRAM 
get-attendees;  ENSURE_ATTENDANCE 
ootpoti 

pgm:  CONF_PROGRAM 

correspondence-sent:  class  -of  CONF_COMMUNIQUE 
poctcondltiooi 

pgm-rcady-by-dcadlinc:  BEFORE(make-pgm , plans •  pgm-deadlinc) 
good-attendance-expected: 

GT(card(ATTENDEE), plans  •  i^attendees-wanted) 


The  activity  has  three  control  properties:  papers,  conference  plans  and  the  communiques 
received.  [1]  The  parts  properties  show  that  the  activity  of  organizing  a  working  conference 
involves  initiating  the  conference,  establishing  the  program  for  the  conference  and  ensuring 
that  the  conference  is  well  attended.  (The  second  subactivity  happens  to  be  the  responsibility 
of  the  Program  Committee  (PC)  while  the  third  is  the  responsibility  of  the  Organizing 
Committee  (OC).) 

Outputs  of  the  activity  (i.e.  objects  inserted  into  the  property  value  classes  during  the 
course  of  the  activity)  are  the  conference  proceedings,  the  conference  program,  and  the 
correspondence  sent  out.  The  postconditions  assert  that  the  activity  is  supposed  to  meet  the 
deadlines  for  the  program  and  proceedings  and  that  good  attendance  is  to  be  expected. 

Now  we  will  look  at  the  second  subactivity,  that  of  establishing  the  conference 
program. 


[1]  Recall  that  Input  is  defined  as  being  removed  from  the  property  value  class  while  a  control 
does  not  have  this  assertion  made  about  it  (which  is  not  the  same  as  saying  the  control  is  NOT 
removed  (nor  inserted  into  another  class),  since  some  OTHER  activity  might  coincidentally 
remove  it  (or  insert  it)  during  the  occurrence  interval).  Thus,  for  example,  we  had  a  choice 
of  how  to  model  'corr-recd';  we  made  it  an  instance  of  a  very  general  (meta-)  class  of  which  it 
remains  an  instance  and  is  therefore  regarded  as  a  control,  whereas  we  could  have  had  it 
become  instance  of  a  class  (say  a  class  of  communiques  not  received)  of  which  it  is  no  longer 
an  instance  after  the  activity  occurs.  For  another  example,  we  could  have  the  'papers' 
property  have  as  property  value  "class  -of  PAPERS_FOR_SUBMISSION',  and  then  specify 
that,  during  the  course  of  the  conference  organization  activity,  the  papers  are  removed  from 
that  class,  being  inserted  into  another  class  (not  a  subclass)  of  submitted  papers. 
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ESTABLISH_CONF_PROGRAM  in  ACTIVITY_CLASS  isa  CONF_ACTIVITY  with 

control! 

p:  class  -of  PAPER 

pp:  class  -of  POTENTIAL_PARTICIPANT 
a&r-corr-in:  class  -of  CONF_COMMUNIQUE 

puts 

gct-papcrs:  SOLICIT_CONTRIBUTIONS 
pick-papers:  REVIEW_AND_SELECT_PAPERS 
design-pgm:  DESIGN_PROGRAM 

ODtpats 

conf-pgm:  CONFERENCE_PROGRAM 
a&r-corr-out:  class  -of  CONF_COMMUNIQUE 

constraint 

same-conf :  conf  •  pgm  =  conf-pgm 
a&rl:  Forall  x  in  ENTITY 

{IN(x,a&r-corr-in)  implies 

fIN(x,CORR_FROM_AUTHOR)  or  IN(x,CORR_FROM_REFEREE)I} 
submitted-papers-are-the-papcrs-to-review: 

get-papers  osubmitted-papers  =  pick-papers  opapers-to-review 
postcond 

{IN(x,a&r-corT-out)  implies 

[IN(x,CORR_TO_AUTHOR)  or  IN(x.CORR_TO_REFEREE)D 


Establishing  the  conference  program  has  as  controls:  "conr  (inherited  from 
CONF_ACTIVITY),  papers,  participant  persons,  and  correspondence  received  from  authors 
and  referees.  It  produces  a  conference  program  and  correspondence  sent  to  authors  and 
referees.  The  *same-conf*  constraint  says  that  the  program,  'conf-pgm”,  mentioned  in  this 
activity  is  the  same  one  referred  to  by  the  'pgm*  property  of  'conf'.  Constraints  such  as  this 
one  in  effect  establish  an  equivalence  between  names  used  in  different  places  in  the 
specification.  Another  example  is  the  last  constraint,  which  asserts  that  the  class  of  papers 
ending  up  as  submitted  in  the  first  subactivity  is  the  same  class  as  the  class  of  papers  to  be 
reviewed  by  the  second  subactivity. 

The  eonstraint  *a&rl'  q>ecifies  that  the  instances  of  received  communiques  are  in  fact  either 
messages  from  authors  or  messages  from  referees.  One  could  simplify  constraints  such  as 
these  by  exploiting  their  eommonality.  Suppose  we  had  a  metaclass  whose  instances  are  classes 
formed  as  the  'union'  of  two  classes: 

UNION_CLASS  in  METACLASS  isa  ENTTTY.CLASS  with 

parts 

one:  ENTITY_CLASS 
two:  ENTITY_CLASS 
Invariant 

in-either:  {x  in  SELF  if  f  [IN(x,one)  or  IN(x,two)]} 


The  Invariant  states  that  for  a  typical  instance,  SELF ,  of  UNION_CLASS,  that  an  instance  of 
SELF  is  in  either  of  the  two  classes  forming  their  union.  Now,  the  constraints  for 
ESTABLISH_CONF-PROGRAM  can  be  specified  by: 
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a&rl:  Forall  x  in  a&r-corr-in 

IN(x,  UNION_CLASS(onc;  CORR_FROM_AUTHOR,  two:  CORR_FROM_REFEREE)) 


xSltI:  Forall  z  in  a&r-corr-out 

IN(x,  UNION_CLASS(one:  CORR_TO_AUTHOR,  two:  CORR_TO_REFEREE)) 


[1]  [2]  Looking  at  the  subparts  of  ESTABLISHING_CONF_PRC)GRAM,  wc  define  the  three 
activity  classes.  SOLICIT_CONTRlBUTIONS  ~  send  out  call  for  papers  and  receive  papers 
and  letters  of  intent  REVIEW_AND_SELECT_PAPERS  -  get  referees'  reviews  and  accept  or 
reject  papers  DESIGN_PROGRAM  -•  set  up  a  program  out  of  the  accepted  papers 

We  model  some  a^>ects  of  soliciting  contributions  in  the  activity  class  definition  below. 

SOLICIT_CONTRIBUTIONS  in  ACTIVITY_CLASS  isa  CONF_ACTIVITY  with 
controb 

papers:  class  —of  PAPER 
replies:  class  —of  LETTER_OF_INTENT 
parts 

caU:  ISSUE_CALL_FOR_PAPERS 
riot:  RECEIVE_LETTERS_OF_INTENT 
rpaps:  RECEIVE-PAPERS 
ootpot 

submitted-papers:  class  -of  SUBMITTED_PAPER 
call-for-papers:  CALL_FOR_PAPERS 
ack-letters:  class  -of  ACK_LETTER 

constraint 

call-before-receive:  BEFORE(call,rlot)  and  BEFORE(call^aps) 


This  activity  has  as  controls  the  papers  received  by  the  program  committee  and  the  replies 
from  authors.  The  parts  describe  putting  out  the  call  for  papers,  receiving  the  letters  of 
intent,  and  receiving  papers  for  submission.  The  constraint  says  that  the  'call'  subactivity 
happens  before  the  others.  The  outputs  are  submitted  papers  (which  arc  passed  on  for 
reviewing  to  the  REVIEW_AND_SELECT  activity);  the  call  for  papers;  and  letters  sent  to 
authors  acknowledging  the  receipt  of  the  submitted  papers. 

The  issuing  of  the  call  for  papers  is  defined  as  follows. 


[1]  isa  could  also  be  used,  ijc.: 

a&rl:  ISA(a&r-corr-in,  UNION_CLASS(onc:  CORR_FROM_AUTHOR,  two:  CORR_FROM_REFEHp 
a&r2:  ISA(a&r-corr-out,  UNION_CLASS(one:  CORR_TO_AUTHOR,  two:  CORR_TO_REFEREE)) 

[2]  In  Chapter  4,  I  proposed  that  there  be  special  notation  for  these  kinds  of  common 
expressions,  e.g.  write 

UNION_CLASS(onc:  CORR_TO_AUTHOR,  two:  CORR_TO_REFEREE)  as 
as 

union  -of  CORR_FROM_AUTHOR,CORR_FROM_REFEREE 
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ISSUE_CALL_FOR_PAPERS  in  ACTIVITY_CLASS  isa  MAILING_ACTIVITY  with 

control 

mailing-list:  class -of  ADDRESS 
call-content:  TEXT 
ontpnt 

call-copies:  class  -of  ANNOUNCEMENT 

postcond 

copies-have-content:  Forall  a  in  call-copies 
a  •  message  =call  •  text 
copies-sent-per-list : 

Forall  a  in  mailing-list 
exists  c  in  call-copies 

COMMUNIQUE_SENT(sender:pc  •  chpn, 
destination  •  addr:a, 
thing-to-sendx) 


The  controls  consist  of  the  text  for  the  call  for  papers  (not  further  analyzed  here)  and  a  list  of 
addresses  where  copies  of  the  call  for  papers  should  be  sent.  Copies  of  the  call  for  papers  are 
output.  The  postconditions  say  what  must  be  true  by  the  time  the  activity  is  through,  in 
particular  that  each  copy  has  the  content  of  the  call-for-papers  and  that  every  address  on  the 
mailing  list  is  a  destination  of  some  copy.  The  assertion  class,  SEND_COMMUNIQUE  has 
three  argoment  properties  which  are  referred  to  here. 

We  now  look  at  what  is  involved  in  reviewing  and  selecting  papers  for  a  conference. 
The  activity  class  REVIEW_AND_SELECT_PAPERS  is  defined  as  follows. 
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REVIEW_AND_SELECT_PAPERS  in  ACTIVITY_CLASS  isa  CONF_ACTIVnT  iviVA 
controls 

papcr»-to-rcview:  class  —of  SUBMITTED_PAPER 
potential-referees:  class  -of  POTENTIAL_REFEREE 
refercc-corr-in:  class  -of  CORR_FROM_REFEREE 
parts 

assign-referees:  ASSIGN_REFEREES 
get-reviews:  GET_REVIEWS 
pick-papers:  SELECT_PAPERS 
ootpots 

referee-corr-out:  doss  —of  DECISION_LETTER 
reviewed-papers:  class  -of  PAPER 
postconds 

enough-papers:  GT(card(SUBMnTED_PAPER),pIan  •  #paper8_wanted) 
make-decisions: 

Forall  p  in  papers-to-review 
Exists  1  in  DECISION_LETTER  such  that 
!•  paper  =p 

constraints 

reviewed-papers- are-assigaed: 

papers-to-review  =assign-referees  •  papers-to- assign 
ref-replies-are-corr-in: 

ISA(assign-referee  •  ref-replies^eferee-corr-in) 
ref-requests-are-corr-out : 

ISA(assign-referee  •  referee- request  ^eferce-corr-out) 


Controls  on  this  activity  are  the  papers  to  be  reviewed,  the  potential  referees,  and  the 
correspondence  from  referees.  The  outputs  are  the  reviewed  papers  and  letters  to  the 
authors.  The  postconditions  say  that  the  result  of  the  activity  is  to  receive  enough  papers  and 
to  issue  a  decision  letter  (accept  or  reject)  for  every  paper  submitted.  The  three  parts  describe 
reviewing  and  selecting  papers  in  terms  of  three  subactivities,  namely  assigning  referees  to  the 
papers,  getting  reviews  from  them,  and  selecting  papers  based  on  the  reviews.  The  constraints 
relate  the  activity  to  its  parts  at  all  times  during  the  activity,  by  saying  (1)  the  papers  to  review 
are  the  ones  to  be  assigned  to  referees,  (2)  each  referee’s  reply  received  during  the  assigning 
of  referees  is  also  one  of  the  pieces  of  referee  corre^ondence  received  in  the  overall  activity 
of  reviewing  and  selecting,  and  (3)  each  request  for  a  referee  to  review  a  paper  is  also  an 
instance  of  correspondence  sent  to  referees. 

Let  us  look  at  the  activity  class,  ASSIGN_REFEREES  to  see  the  connection. 
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ASSIGN_REFEREES  in  ACTIVITY_CLASS  isa  CONF_ACTIVITY  with 
control 

papervto-assign:  class  -of  SUBMnTED_PAPER 
referee-replies:  class  -of  REVIEW_REPLY 
referee-pool:  class  -of  POTENTIAL_REFEREE 

part 

assign-refs-to-each-paper:  class  -of  ASSIGN_REFEREE 

ontpat 

referee-requests:  class  -of  REQUEST_FOR_REFEREE 
constraint 

assign-each-paper: 

Forall  X  in  papers-to-assign 

exists  y  in  assign-refs-to-each-paper  with 
y  a  paper-to-assign  =x 


AiMrtlons 

Assertions  play  important  roles  in  the  entity  and  activity  class  definitions  above.  Here 
we  give  an  example  of  assertions  organized  on  an  ISA-hierarchy. 

We  use  an  assertion  class  to  contain  statements  saying  that  some  potential  referee  is 
an  allowed  choice  to  referee  a  certain  paper. 

ALLOWED_CHOICE_OF_REFEREE  isa  ASSERTION  with 

argnments 
p:  PAPER 

r:  POTENTIAL_REFEREE 

defn 

same-subject:  r*q>ecialty  =  po  subject 
not -own-paper:  nor  IN(r,po  authors) 


Potential  referee  r  is  an  allowed  choice  for  paper  p  if  the  person’s  ^}eciality  is  the  same  as  the 
subject  of  the  paper  and  r  is  not  one  of  the  authors  of  p. 

Now  we  can  define  what  it  means  to  have  a  'good'  choice  of  referee  for  a  paper. 

GOOD_CHOICE_OF_REFEREE  isa  ALLOWED_CHOICE_OF_REFEREE  with 

defn 

not-overloaded:  not  TOO_MANY_PAPERS(r) 


Another  condition  is  added,  making  a  'good'  choice  of  referee  one  who  has  not  been  assigned 
too  many  papers. 

Now,  we  define  the  class  of  actual  referee/paper  assignments. 
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REFEREE_PAPER_ ASSIGNMENT  isa  ALLOWED_CHOICE_OF_REFEREE 

made  true  by 

sending:  SEND_PAPER_TO_REFEREE 
cooftralnt 

send-to-r:  sending* ref  =  r 


The  ISA-hierarchy  for  these  assertion  classes  is  below. 

ALLOWED_CHOICE_OF_REFEREE 


GOOD_CHOICE_OF_REFEREE  REFEREE_PAPER_ASSIGNMENT 


GOOD_REFEREE_ASSIGNMENT 


We  have  added  to  the  three  assertions  defined  above  a  fourth,  whose  instances  are  actual 
referee  assignments  that  are  'good*. 

GOOD_REFEREE_ASSIGNMENT  in  ASSERTION_CLASS 

isa  GOOD_CHOICE_OF_REFEREE,  REFEREE_PAPER_ASSIGNMENT  with 
toffcond 

good-and- actual: 

Wiself  ,  GOOD_CHOICE_OF_REFEREE) 
and  miself  ,  REFEREE_PAPER_ASSIGNMENT) 
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